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PREFACE. 



Muliics System Designers' Notebooks (SDNs) are intended for 
use by Multics system maintenance personnelj development person- 
nelj and others who are thoroughly familiar with Multics internal 
system operation. They are not intended for application 
programmers or subsystem writers. 



The SDNs contain descriptions of modules that serve as 
internal interfaces and perform special system functions. These 
documents do not describe external interfaceSj which are used by 
application and system programmers. 



This SDN contains a description of the software that 
initializes the Multics system. This description is by no means 
complete in all its details; for a thorough understanding of 
Multics ini t ial izat ionj or of any particular area within this 
systemj this SDN should be used for reference in conjunction with 
the source of the relevant programs. 



(C) Honeywell Information Systems Inc., 1984 
3/84 



Fi le No. : 2L13 
AN70-01 



In addition to this manual j the volumes of the Mu 1 1 i cs 
Programmers ' Manua l ( MPM) should be referred to for details of 
software concepts and organ i zat i on^ external interfacesj and for 
specific usage of Multics Commands and subroutines. These 
volumes are: 

MPM Reference QiiLdfi. Order No. AG91 

l^EH QQm^n<H^ aOSL Agl^W^ Fungi^iQna^ Order No. AG92 

MPM Subrout ines . Order No. AG93 
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SECTION 1 
SUMMARY OF INITIALIZATION 



Mul'tics ini t ial izatiortj as described in this SDNj can be 
thought of as divided into the following parts: 



* Hardware and PL/1 Environment initialization (Collec- 
tion 0) 

* Page Control initialization (Collection 1 service pass) 

* Boot load Command Environment (bee) (Collection 1 multi- 
ple passes) 

* Crash Handler (toehold) 

* File System initialization (Collection 2) 

« Outer ring Environment initialization (Collection 3) 



The parts listed before collection 2 are collectively called 
"Bootload Multics." 



A collection is simply a set of initialization routines 
that are read in and placed into operation as a unit to perform a 
certain setj or a certain subset j of the tasks required to 
initialize a portion of the Multics supervisor. Each collection 
consists of a distinct set of programs for reasons discussed 
throughout this SDN, Even though each collection mostly exists 
to perform a particular set of functions^ they are normally 
referred to by their number (which have only historical signifi- 
cance) rather than the name of their function. 



Initialization may also be thought of as having three 
separate functions: 

Bringing up the system 

This role is obvious. The description of this role 
follows along the functions needed to perform it. Each 
portion of initialization runSj utilizing the efforts 
of the previous portions to build up more and more 
mechanism until service Multics itself can run. 



Providing a command environment before the file system is 
activated from which to perform configuration and disk 
maintenance functions 
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Providing an environment to which service Multics may crash 
which is capable of taking a dump of Multics and 
initiating recovery and reboot operations 

These last two functions are the role of boot load Multics 
C bee) . They take advantage of the fact that during 
initialization an environment is built that has certain 
facilities that allow operations such as disk manipulation to 
occur but it is an environment in which the disks themselves are 
not yet active for storage system operations. This environment, 
at an intermediate point in ini tial ization^ forms the boot load 
command environment (bee). 

The boot load command environment is saved before further 

initialization operations occur. When service Multics crashes^ 
service Multics is saved and this bee "crash" environment is 
restored, This safe environment can then examine or dump the 
service Multics image and perform certain recovery and restart 
operations without relying on the state of service Multics. 



HARPWAf^^ am EU± ENVIPgNMENT I NI TIALt NATION 

The purpose of collection 0 is to set up the pl/1 
environment and to start collection 1. It has a variety of 
interesting things to perform in the process. First of allj 
collection 0 must get itself running. When Multics is booted 
from BOSj this is an easy matterj since BOS will read in the 
beginning of collection Oj leaving the hardware in a known and 
good state and providing a description of the configuration 
(conf igLdeck) around. When not booted from BOSj that is, when 
booted via the lOM boot functionj collection 0 has the task of 
getting the hardware into a good and known state and finding out 
on what hardware it is working. 0nce collection 0 has set up the 
hardware, it can load collection 1 into memory. Collection 1 
contains the modules needed to support programs written in pl/1; 
thus, this loading activates the pl/1 environment. After this 
time, more sensible programs can run and begin the true process 
of initialization. The result of this collection is to provide 
an environment in which pl/1 programs can run, within the 
conf i nes of memory. 



PAGE COMIESL iMlXLALIZ&Xim 

The main task of collection 1 is to make page control 
operative. This is necessary so that we may page the rest of the 
initialization programs (initialization programs all have to fit 
into memory until this is done). The initialization of page 
control involves setting up all of the disk and page control data 
bases. Also, the interrupt mechanism must be initialized. The 
result of this collection is to provide an environment in which 
i/o devices may be operated upon through normal mechanisms (i.e.. 
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via page faults or direct calls to the standard device control 
modules) but in which the storage system is not active. At the 
final end of collection 1j this environment becomes paged, using 
a special region of the disks (the hardcore partition) so that 
the storage system is not affected. 

Collection 1 can be run multiple times. The effect of 
making a pass through collection 1 is to set up the device tables 
(and general configuration describing tables) to reflect a new 
configuration. The various passes of collection 1 are the key to 
the operation of bee. There are several times when the running 
of collection 1 is necessary. It is necessary when we first 
start upj to allow accessing the hardware units "discovered" by 
collection 0. Once the correct configuration is determined via 
bee activitieSj collection 1 must be re- run to allow all of the 
devices to be accessible during the rest of initialization and 
Multics service proper. Final ly, when the crash environment is 
restored (see below) , another pass must be made to provide 
accessibility to the devices given the state at the time of the 
crash. 



FILE SYSTEM INITIALIZATION 

With paging active, collection 2 can be read into a paged 
environment. Given this environment, the major portion of the 
rest of initialization occurs. Segment, directory and traffic 
control are initialized her©, making the storage system accessi- 
ble in the process. The result of this collection is an 
environment that has active virtually all hardcore mechanisms 
needed by the rest of Multics. 



O MT E R RING ENVIRONMENT tNITIAHZATtON 

Collection 3 is basically a collection of those facilities 
that are required to run in outer rings. In particular, it 
contains the programs needed to provide the initializer's ring 
one environment, especially the code to perform a reload of the 
system (especially the executable libraries). After the execu- 
tion of this collection, the Initializer enters into a ring one 
command environment, ready to load the system ( if necessary) and 
start up the answering service. (Activities performed from ring 
one onward are not covered in this SDN. ) 



eOOTtOAP QOMMANQ. ENVIRONMENT ( ^CE ? 

The boot load command environment is an environment that can 
perform configuration and disk management functions. It needs to 
be able to support i/o to devices in a pl/1 environment. Also, 
since bee must be able to operate on arbitrary disks, it must be 
capable of running before the storage system is active, Thus, it 
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is equivalent to the collection 1 environment before the environ- 
ment becomes paged. In this environmentj built by a special run 
of collection 1j a series of facilities provides a command 
environment that allows pl/1 programs to run in a manner similar 
to their operation in the normal Multics programming environment. 



QP A?H HANPUFR (TSgHQLP^. 

When Multics has cp ashed j Multics is incapable of 
performing the types of analysis and recovery operations desired 
in its distressed state. ThuSj a safe environment is invoked to 
provide these facilities. Since bee is capable of accessing 
memory and disks independently of the storage system (and the 
hardcore partitions) , it becopies the obvious choice for a crash 
environment. When Multics crashes^ bee is restored to operation. 
Facilities within bee can perform a dump of Multics as well as 
start recovery and reboot operations. The crash environment 
consists of the mechanisms needed to save the state of Multics 
upon a crash and to re- setup the boot load command environment. 
These mechanisms must work in the face of varying types of system 
failures; they must also work given the possibility of hardware 
reconfiguration since the time the safe environment was saved. 
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SECTI0N 2 



COLLECTION 0 



QoHection 0 in Bootload Hultics is an ensemble of ALM 
programs capable of being booted from BOS or the lOM^ reading 
themselves off of the boot tape^ loading tape firmware if needed^ 
setting up an I/O and error handling environmentj and loading 
CO 1 1 ect i on 1 . 

Collection 0 is organized into two modules: 
bootload_tape_ label J and bound_bootload_0. The first is an MST 
label program designed to read the second into its correct memory 
location J after being read in by the lOM boot load program. The 
second is a bound collection of ALM programs. bound_boot load_0 
takes extensive advantage of the binder's ability to simulate the 
linker within a bound unit. The programs in bound_boot load_0 use 
standard external references to make intermodule refer ences^ and 
the binder^ rather than any run-time linker or pre-linfcerj 
resolves them to TSR-relative addresses. Any external references 
(such as to the config deck) are made with explicit use of the 
fact that segment numbers for collection 0 programs are fixed at 
assembly time. 



QETTINQ STARTED 

boot I oad_tape_ label is read in by one of two means. In 
native mode^ the lOM or I IOC reads it into absolute location 30^ 
leaving the PCW, DCW s^ and other essentials in locations 0 
through 5. The II OC leaves an indication of its identity just 
after this block of information. 

In BOS compatibility mode^ the BOS BOOT command simulates 
the lOMj leaving the same information. However j it also leaves a 
config deck and flagbox (although bee has its own flagbox) in the 
usual locations. This allows Bootload Multics to return to BOS 
if there is a BOS to return to. The presence of BOS is indicated 
by the tape drive number being non-zero in the idcw in the "lOM" 
provided information. 
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The label overlays the interrupt vectors for the first two 
lOM's. Because the label is formatted as a Multics standard tape 
recordj it has a trailer that cannot be changed. This trailer 
overlays the interrupt vectors for channels B9 and 810. Without 
a change in the label formatj the bootload tape controller cannot 
use either of these channels as a base channel j because the label 
record wipes out the vectors that the lOM bootload programs sets 
up. This prevents control from transferring to the label 
program. 

The label program first initializes the processor by 
loading the Mode Register and the Cache Mode Registerj and 
clearing and enabling the PTWAM and the SDWAM. It then reads all 
of bound_bootload_0 off the tape. This action places the toehold 
and boot load_ear ly_dump into their correct places In memory, in 
as much as these two modules are bound to be the first two 
objects in bound_boot load_0. If this is successful j it transfers 
to the beginning of boot load_abs_ mode through an entry in the 
toehold. (This entry contains the address of boot load_abs_modej 
via the linicing performed by the binder.) This program copies 
the template descriptor segment assembled into template_slt_ to 
the appropriate locationj copies int_unpaged_page_ tables and 
unpaged_page_ tables to their correct locationSj loads the DSBR 
and the pointer registers, enters appending mode, and transfers 
to bootload_0. 



pRQgRAriMINE m COLUPTION fi 

Collection 0 programs are impure assembly language pro- 
grams. The standard calling sequence is with the tsx2 instruc- 
tion. A save stack of index register 2 values is maintained 
using id and di modifiers, as in traffic control. Programs that 
take arguments often have an argument list following the tsx2 
instruction. Skip returns are used to indicate errors. 



The segment boot load_ info, a cds program, is the repository 
of information that is needed in later stages of initialization. 
This includes tape channel and device numbers and the like. The 
information is copied into the collection 1 segment sys_boot_ inf o 
when collection 1 is read in. 



MQPULE DESCRIPTIONS 



bootload abs mode .aim 

As mentioned above, boot load_abs_ mode is the first program 
to run in bound_bootload_0. The label program locates it by 
virtue of a tra instruction at a known place in the toehold 
(whose address is fixed)j the tra instruction having been fixed 
by the binder. It first clears the memory used by the Collection 
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0 data segmentSj then copies the template descriptor segment j 
int_unpaged_page_ tables and unpaged. page_ tables from 

template_slt_ . The DSBR is loaded with the descriptor segment 
SDWj the pointer registers are filled in from the ITS pointers in 
template.sl t_ J and appending mode is entered. boot load. abs_ mode 
then transfers control to bootload_0$beginj the basic driver of 
collection zero initialization. 



l;><?Qt.\og(<;a o.^lm 

bootload_0's contract is to set up the I/O, faulty and 
console services^ and then load and transfer control to collec- 
tion 1. As part of setting up the I/O environmentj it must load 
tape firmware in the boot load tape MPC if BOS is not present. 
bootload_0 makes a series of tsx2 calls to set up each of these 
facilities in turn. It calls boot load_ ioSprei nit to interpret 
the bootload program left in low memory by the I GM/ 1 I OC/ 1 OXj 
including checking for the presence of BOS; 

bootload_f lagboxSpreinit to set flagbox flags according to the 
presence of BOSj boot load_f au I ts$ i n i t to fill in the fault 
vectorj boot I oad_ si t_ managers i n i t_s It to copy the data from 
template_slt_ to the SLT and name_ table] bootload_ io$ ini t to set 
up the I/O environmentj boot load. consoles in it to find a working 
console and initialize the console package; boot I oad_ loaders ini t 
to initialize the MST loading packagej boot load_tape_fw$ boot to 
read the tape firmware and load it into the bootload tape 
controller; boot load_ loaders load_col lect i on to load Collection 
1 . Oj bootload. I oaderSf in ish to copy the MST loader housekeeping 
pointers to their permanent homes; and bootload. I inker Spr el ink to 
snap all links in Collection 1.0. 

Finallyj the contents of bootload. i nfo are copied into 
sys. boot. info. Control is then transferred to bootload.l. 

lbs. f i rmwarg gpugc^ictni 

As described below under the heading of 

" boot load. tape. fw. aim" J tape firmware must be present on the MST 
as ordinary segments. It must reside in the low 256Kj because 
the MPC's do not implement extended addressing for firmware 
loading. The tape firmware segments are not needed after the MPC 
is loadedj so it is desired to recycle their storage. It is 
desired to load the MPC before collection 1 is loadedj so that 
backspace error recovery can be used when reading the tape. The 
net result is that they need to be a separate collection. To 
avoid destroying the old correspondence between collection num- 
bers and sys_ i nf o$ i n i t i al i zat i on.state values^ this set exists as 
a sub- CO 1 1 ect i on . The tape firmware is collection 0.5^ since it 
is loaded before collection 1. The segments in collection 0.5 
have a fixed naming convention. Each must include among its set 
of names a name of the form "fwid. Tnnn"j where "Tnnn" is a four 
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character controller type currently used by the BOS FWLOAD 
facility. These short names are retained for two reasons. 
Firstj they are the controller types used by Field Engineering. 
Secondj there is no erase and kill processing on input read in 
this environment J so that short strings are advantageous. Note 
that if the operator does make a typo and enters the wrong 
str i ngj the quest i on is asked aga i n . 



boot I pad console .aim 

boot I oad_ console uses bootload_io to do console I/O. Its 
initialization entry^ initj finds the console on the boot load 
ISM. This is done by first looking in the config deck^ if BOS 
left us onej or^ if notj by trying to perform a 51 (Write Alert) 
commen'^ to each channel In turnJ . Only console channels respond 
to this command. When a console is founds a 57 (Read ID) command 
is used to determine the model. 

The working entrypoints are writej write_nlj write_alertj 
and read_line. write_nl is provided as a convenience. All of 
these take appropriate buffer pointers and lengths. Read_line 
handles timeout and operator error statuses. 

There are three types of console that boot I oad_ console must 
support. The first is the original EMCj CSU6001 . It requires 
all its device commands to be specified in the PCWj and ignores 
IDCW's. The second is the LCC, CSU6601 . It will accept commands 
in either the PCW or IDCW's. The third type is the iPC-CONS-2. 
In theoryj it should be just like the LCC except that it does NOT 
accept PCW device commands. Whether or not it actually meets 
this specification has yet to be determined. 

To handle the two different forms of I/O (PCW commands 
versus IDCW's) j boot I oad_ console uses a table of indirect words 
pointing to the appropriate PCW and DCW lists for each operation. 
The indirect words are setup at initialization time. The LCC is 
run with IDCW's to exercise the code that is expected to run on 
the IPC-CONS-2. 



bQQt^Qad dgpg.^^m 

boot load_dseg' s task is to prepare SDW's for segments 
loaded by boot I oad_ loader j the collection zero loader. 
bootload_dseg$make_sdw takes as an argument an sdw_info structure 
as used by sdw_util_j and constructs and installs the SDW. The 
added entrypoint boot load. dsegS make. cor e_ptw is used by 
boot I oad_ loader to generate the page table words for the unpaged 
segments that it creates. 
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boo^load early dump .aim 



When an error occurs during early initial izationj 
bootload_ear ly.dump is called. It is called in three ways. 
First J if boot load_ error is called for an error (as opposed to a 
warning)^ this routine is called. Secondlyj if a crash should 
occur later in initialization (after collection 0) but before the 
toehold is set up (and bee running)j the toehold will transfer 
here. Thirdj the operator can force a transfer to this routine 
through processor switches any time up until col lect_f ree_core 
runs. (This includes while bee is running.) This is done by 
force executing a "tra SOOOOo" instruction. 

boot load_ear ly_dump starts by reestablishing the collection 
0 environment (masked^ pointer registers appropriately setj 
etc. ) . It then uses boot I oad_ console to ask. for the number of a 
tape drive on the bootload tape controller to use for the dump. 
When it gets a satisfactory answer j it dumps the first 512k of 
memory (that used by early initialization and bee) j one record at 
a timej with a couple of miscellaneous values used by 
read_ear ly_dump.tape (which constructs a normal format dump). If 
an error occurs while writing a record^ the write is simply 
retried (no backspace or other error recovery). After 16 
consecutive errors^ the dump is aborted^ a status message 
printedj and a new drive number requested. 



b9oi^iop<?i grrQPi glim 

bootload_ error is responsible for all the error messages in 
collection 0. It is similar in design to page_error . aim; there 
is one entrypoint per message^ and macros are used to construct 
the calls to bootload_f orml ine and bootload_console. 
boot I oad_ err or also contains the code to transfer to 
bootload_ear ly_dump. There are two basic macros used: "error"j 
Which causes, a crash with messagsj and "warning" j which prints 
the message and returns. All the warnings and errors find their 
parameters via external references rather than with call parame- 
ters. This allows tra's to boot I oacL error to be put in error 
return slotSj like: 

tsxS read_word 

tra bootload_error$console_error 

" error J status in 

" boot I oad_ conso I e* I ast_ er r or_ status 
... " normal return 

Warnings are called with tsx2 calls. 
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boot I oad_ faults sets up the segment fault_ vector. All 
faults except timer runout are set to transfer to 
boot load_error$unexpected_f ault. All interrupts are set to 
transfer control to boot load_error$unexpected_ i nterrupt^ since no 
interrupts are used in the collection zero environment. The same 
structure of transfers through indirect words that is used in the 
service fault environment is used to allow individual faults to 
be handled specially by changing a pointer rather than 
constructing a different tra instruction (also^ instructions do 
not allow "its" pointers within them). The structure of the 
scu/tra pairs (but not the values of the pointers) formed by 
bootload_f aul ts is that used by the rest of initialization and 
servi ce. 



boot I pad flaabox.alw 

boot load_f lagbox zeroes the bee f lagbox. It also zeroes 
the cold_di sk_mpc flag when BOS is present for historical 
reasons. Various values are placed in the f lagbox that no one 
looks at, This program is responsible for the state of the BOS 
toehold as well. It copies the BOS entry sequences into the bee 
toehold and sets the bee entry sequence into the BOS toehold for 
the sake of operators who enter the wrong switches. 



boatload form lin e .aim 

This program is a replacement for the BOS erpt facility- 
It provides string substitutions with ioa„-like format controls. 
It handles octal and decimal numbersj BCD characters^ asci i in 
units of words, and ACC strings. Its only client is 
boot load_errorj who uses it to format error message. The BCD 
characters are used to print firmware ID'S found in firmware 
images. Its calling sequence is elaborate^ and a macrOj 
"formline"j is provided in bootload_f orml ine. incl . aim 



boot I pad info.cds 

The contents of this segment are described under data 

bases. 



boot load io.alm 

bootload_io is an io package designed to run on lOM's and 
I IOC's. It has entrypoints to connect to channels with and 
without timeouts. It always waits for status after a connection. 

It runs completely using abs mode i/Oj and its callers must fill 
i.n their DCU lists with absolute addresses. This is done because 
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NSA lOM's do not support rel mode when set in PAGED modej and 
there is no known way to find out whether an lOM is in paged 
mode. Under normal operationj the config card for the lOM is 
available to indicate whether the I ON is in paged mode or notj 
relieving this difficulty. 

The preinit entrypoint is called as one of the first 
operations in collection 0. Besides setting up for i/o, it 
copies and determines from the IQM/IIOC/BQS provided boot info 
the assume_conf ig_deck (BOS present) flag and the system_type 
value. 



bo ot load linker. aim 

boot I oad_ I i nker is responsible for snapping all links 
between collection one segments. It walks down the LOT looking 
for linkage sections to process. For each onej it considers each 
link and snaps it. It uses boot I oad_ si t_ managers get_seg_ptr to 
find external segments and implements its own simple definitions 
search. 



boot load loader .aim 

boot I oad_ loader is the collection zero loader (of collec- 
tions 0,5 and 1). It has entrypoints to initialize the tape 
loader (init)j load a collection ( load_col lect i on) j skip a 
collection ( ski p_ col lection) j and clean up (finish). The loader 
is an aim implementation of segment. loader . pi 1 j the collection 1 
loader. It reads records from the mstj analyzes themj splitting 
them into sit entrieSj definitions and linkage sectionSj and 
segment contents. Memory is obtained for the segment contents 
using allocation pointers in the sit. Page tables are allocated 
for the segment within the appropriate unpaged_page_ tables seg- 
ment. When proper, th© breakpoint^ page is added as another page 
to the end of the segment. Definitions and linkage sections are 
added to the end of the proper segments (ai_linksgej wi.linkage, 
ws.linkage, as.linkage). The loader has a table of special 
segments whose segment numbers (actually ITS pointers) are 
recorded as they are read in off of the tape. These include the 
hardcore linkage segments^ needed to load linkage sections, 
def i n i t i ons_, and others. The loader maintains its current 
allocation pointers for the linkage and definitions segments in 
its text. boot I oad_ I oader$ f i n i sh copies them into the headers of 
the segments where segment. I oader expects to find them. 



boot load sit manager .aim 

boot I oad_s I t_ manager is responsible for managing the Seg- 
ment Loading Table (SLT) for collection zero. It has three 
entries. bootload_slt_manager$ ini t_slt copies the SLT and name 
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table templates from template^sl t_ to the sit and name_table 
segments. boot I oad_s I t_ managers bui I d_ entry is called by 
boot I oad_ loader to allocate a segment number and fill in the SLT 
and name table from the information on the MST. 
boot I oad_slt_ managers get_seg_ptr is called by boot I oad_ I i nker to 
search the SLT for a given name. It has imbedded in it a copy of 
hash_index_ used to maintain a hashed list of segment names 
compatible with the list for slt_manager in further collections. 



boot I pad tape fw.aln 

boot load_tape_f w is responsible for loading the boot load 
tape MPC. It begins by loading collection 0.5 into memory with a 
call to boot I oad_ loaders I oad_ col lection. By remembering the 
value of sit. last_ init_seg before this call^ bootload_tape_f w can 
tell the range in segment numbers of the firmware segments. 
Firmware segments are assigned init_seg segment numbers by 
boot I oad_ loader J but are loaded low in memoryj for reasons 
described above. bootload_tape_f w then determines the correct 
firmware type. If boot load_ info specifies the controller type^ 
then it proceeds to search the SLTE names of the firmware 
segments for the appropriate firmware. If bootload_ inf o does not 
specify the firmware type^ then boot load_tape_f w must ask the 
operator to supply a controller type. This is because there is 
no way to get a controller to identify itself by model. 

Each of the firmware segments has as one of its SLTE names 
(specified in the MST header) the six character MPC type for 
which it is to be used. bootload_tape_f w walks the sit looking 
for a firmware segment with the correct name. If it cannot find 
itj it re- queries (or queries for the first time) the operator 
and tries again. 

Having found the right f irmwarej the standard MPC boot load 
sequence is initiated to boot the tape MPC The firmware 
segments' SDW s arc zeroed, and the sit allocation pointers 
restored to their pre-col lect i on-0. 5 values. boot load_tape_f w 
then returns. 



template sit .aim 

This aim program consists of a group of involved macros 
that generate the SLTE's for the segments of collection zero. It 
is NOT an image of the segment sltj because that would include 
many zero SLTE's between the last sup seg in collection zero and 
the first init seg. Instead^ the in it seg SLTE's are packed in 
just above the sup segSj and bootload_slt_manager$ ini t_slt 
unpacks them. It also contains the template descriptor segment, 
packed in the same manner, and the template name table. The 
initial contents of int_unpaged„page_ tables and 

unpaged_page_ tables are also generated. Also present are the 
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absolute addresses, lengths, and pointers to each of the collec- 
tion 0 segments for use elsewhere in bound_boot loadLO. 
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SECTION 3 



C0LLECTI0N 1 



The basic charter of coHect,ion 1 is to s«t up paging^ 
fault handling^ as well as various data bases needed for paging 
and other like activities. Collection 1 can run multiple timeSj 
for various reasons. 



SUMM A RY QE. pgLln E CT lQN 1 PAS S ES 

The first run through collection 1 is known as the "early" 
pass which is described below. It is a run in which we are 
restricted to work, within 51 2K and in which only the rpv is 
known; in factj it is this pass which finds the rpv and the 
config deck. If BOS is present j this pass is not needed. The 
end of this pass is the arrival at "early" command levelj used to 
fix up the config deckj in preparation for the "boot" pass. 

The second passj which is known as "boot load Multics 
initial ization" J also runs only within 512K. It^ howeverj has 
knowledge of all disks and other peripherals through the config 
deck supplied either by BOS or the early initialization pass. 
This pass is made to generate a crash- to-able system that can be 
saved onto disk for crash and shutdown purposes. After the crash 
handler (this image) is saved^ the boot load Multics "boot" 
command level can be entered. This level allows the booting of 
Multics service. After Multics has shut downj a slight variant 
of this pasSj the "shut" pass^ is run in a manner similar to that 
for the "crash" pasSj described below. 

The third pass (which actually comes after the fourth) is 
another run of boot load Multics initialization performed after 
Multics has crashed. This pass is made to re- generate various 
tables to describe the possibly different configuration that now 
exists after having run Multics. Boot load Multics "crash" 
command level is then entered. 

The fourth pass through collection 1 is called "service 
ini tial izat ion" J which runs using all memory and devices, The 
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result of this pass is suitable for running the later collec- 
tionSj and bringing up service. 

The "early" pass creates a safe environment consisting of a 
set of programs in memory and a synthesized conf ig deck that 
describes known hardware. This is saved away to handle crashes 
during the "boot" pass. If the "boot" pass failSj the toehold 
restores this earlier saved environment which then runs a 
"re_early" pass. This is really a normal pasSj but using the 
saved away conf ig deck of known good hardware. The "re_ early" 
pass comes back to an "early" command level to allow the operator 
to fix the deck or hardware. 

When the "boot" pass succeeds^ it also saves a good memory 
image and the now confirmed site config deck. After the "boot" 
pass saves this image, the "boot" command level is entered and 
eventually it boots Multics, running the "service" pass. If this 
failSj the toehold restores the saved image. A "bce_ crash" pass 
then runs. This is a normal pass but one in which the saved 
config deck is used. This pass is run on the assumption that, 
either a bee command died and the operator may now examine it, or 
that the "service" pass found a problem, The "bce_crash" level 
allows the operator to fix things. 

Once the boot of service Multics completes collection 1j a 
crash or shutdown will invoke the toehold to restore bee. This 
timej however J the current config deck is used to utilize any 
reconfigurations that have occured. bee will come to the "crash" 
or "boot" command levels. 

We'll start by looking at the basic initialization pass, 
that used to come to the normal ("boot") bee command level. 



mBML <PO0T) PASS 

The sequence of events in a normal initialization pass is 
given here. As of the time of the start of a normal 
initialization pasSj the config deck has been founds either by 
BQS or the early initialization pass. All other data bases 
besides sys_boot_ i nf o and sys_info set or created during previous 
initialization passes have been deleted. The pass starts with 
saving certain attributes^ such as free core extentSj for later 
restoration at the end of the pass (before running another). 

ses_and_clock_ init fills in the initial scs (system config- 
uration segment) data from the config deck. This is information 
on the processors and the memory controllers. 

get_io_segSj iom_data_ init^ ocdcm_$ i n i t_al l_consoleSj and 
scas_init are run to set up the disk_segj pvtj iom_dataj 
ioi_dataj oc.data and the system controller addressing segment. 
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tc_init initializes tc_ data's apte and itt lists. 



init_sst generates the sst and core map appropriate for the 
pass. This is the last real memory allocation. After this time^ 
allocation of memory based upon the data in the sit is 
deactivated. The remaining tables either have memory already 
allocated for them or are generated pagedj once paging is 
started. announce. chwm announces memory usage. 

init ial ize_fau I ts$ interrupt. i nit initializes the interrupt 
vector. With iom_data and oc.data set upj this permits ocdcm_ to 
be used for console I/O. The interrupt mask is opened with a 
call to pmut$set_mask. 

The basic command environment facilities C I/O interfaces 
and a free area) are set up in a call to init.bce. <BCE is an 
acronym for Bootload Command Environment). This allows programs 
that query the operator to do so in a more friendly fashion than 
raw calls to ocdcm_ . Further descriptions of bee facilities 
follow later. 



load_di sfc_mpcs runs (only 
when we do not have BOS present) 
have firmware active within them. 



during a "boot" pass and only 
to make sure that all disk mpcs 



init_pvtj read_di sk$ i ni t and ini t_root_vols together have 
the net effect of setting up disk and page control. No segments 
are paged at this time^ though^ except for rdisk_seg. Once we 
reach here, we know that the conf ig deck describes a set of 
hardware sufficient (and valid) enough to reach command level and 
so we save the config deck as safe_ conf ig_ deck. 

establ i sh_temp_segs maps the bootload paged temp segments 
onto the reserved area for them in the "bee" partition, 
f ind_f i le_part i t i on maps the bee file system area 
( bootload_f i le_part i t ion) unto the "file" partition. 

load_mst$ in i t_ commands maps the pagable bee programs onto 
the areas of disk in which they were read by loadLmst earlier. 

If this is a "early" or "boot" passj this environment is 
saved and the toehold setup to invoke it. This is done by 
ini t_toehold. The "early" pass saves the entire environment] the 
"boot" pass simply saves the safe^ conf i g_ deck so determined by 
this pass. 

bce_get_to_ commands level can now be called to provide the 
appropriate bee command level. At the "early" command I eve I j the 
config deck must be made to be correct. At the "boot" command 
I eve I J the mpcs (other than the bootload tape mpc and all of the 
disk mpcs) need to be loaded. 
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Within the command I eve I j the config deck, (on diskj 
disk^conf ig_deck.) may have been modified. This is read in^ via 
establ i sh_conf i g_deck.j for the next initialization pass. For 
cold boots, the generated config deck, is written out instead. 

When the pass is over^ the states saved at the beginning of 
the pass are restored^ the system is masked, and we proceed to 
perform another pass. 



The sequence of events in a service pass differs from the 
normal pass in many ways. 

After initial ize_fauVts$f ault_ init_one runs, 

move_non_perm_wired_segs is called to move the segments loaded by 
collection 0 to their proper places, thereby utilizing all of the 
boot load memory. 

[Collection 0 assumes 512K of boot load memory, for two 
reasons. First, if BOS and the config deck are not present, 
there is no easy way of finding out how much memory there is, so 
some assumption is needed. Second, the crash handler will have 
to run in some amount of memory whose contents are saved on disk. 
51 2K is a reasonable amount of space to reserve for a disk 
partition. At current memory and disk prices it is hard to 
imagine anyone with a boot load controller with less that 512Kj or 
a problem with the disk partition. 

When setting up the service environment, though, it is 
necessary to move the segments that have been allocated in the 
51 2K limit. It is desirable to have sst_seg and core_map at the 
high end of the boot load memory controller. (On the one hand, 
the controller they reside in cannot be deconf i gured. On the 
other hand, only the low 256K of memory can be used for I/O 
buffers on systems with lOM's not in paged mode. While we could 
just start them at the 256K point, that might produce 
fragmentation problems. So the top of the controller is best.) 
If the controller really has 512K of memory, collection 1 paged 
segments will be there. move_non_perm_wired_segs takes the 
segments that the collection zero loader allocated high (paged 
segments and in it segments that are not firmware segments) and 
moves them to the highest contiguously addressable memory, 
hopefully leaving the top of the low controller for the sst_seg 
and core. map. 3 

tc_ i n i t sets the number of aptes and i tt entr i es on the 
basis of the ted card. A normal bee pass really needs no such 
entr ies. 

init_sst generates the sst and core map appropriate for all 
of memory at the top of the boot load memory. A normal pass 
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allocates these tables through normal off-the-slt allocation 
(because the top of the 512k area is filled with temp segs) . 

Since the service pass does not come to bee command I eve I j 
estab I i sh_ temp_ segs^ f i nd_ f i I e_ part i 1 1 on and 

load_mst$ init_ commands are not run. 

init_ toehold is not run since upon a crash we want to 
return to the bootload environment and not to a state in which we 
are booting. 

ini t^parti tions checks the "part" conf ig cards. 

NoWj the routine we've all been waiting for runs. 

make_segs_ paged causes all pagable segments to be paged into the 
various hardcore partitions thereby no longer needing memory. We 
can then run col lect_f ree_core to regain the freed space. 

delet€_segs$temp deletes the segments temporary to collec- 
tion 1. We can then load, link, and run collection 2 (performed 
by segment., loader J pre_link_hc and beyond). 



EMU. P A$$ 

The early initialization pass is a pass through collection 
1 whose job is to set up paging and obtain the conf ig deck from 
its disk partition so that a normal initialization pass may be 
run which knows about the complete set of hardware. 

It starts with init_ear ly_conf ig constructing a conf ig deck 
based on assumptions and information available in sys_boot_ i nf o. 
This config deck describes the bootload CPU, the low 512K of 
memory, the bootload lOM, the bootload tape controller and the 
bootload console. Given this synthetic deck, we can proceed 
through scs_and_clock„initj etc. t© setup the environment for 
paging. scs_and_clock_init$early fills the bootload CPU port 
number into the config deck, which is how it differs from 
scs_and_clock_ ini tSnormal . 

scas^init and init^scu (called from scas.init) have special 

cases for early initialization that ignore any discrepancy 
between the 51 2K used for the bootload controller and any larger 
size indicated by the CPU port logic. 

During the early pass (or, actually during the first "boot" 
pass, if an early pass is never run), ini t_bce($ wired sets up 
references in bce.data to wired objects. This allows 
bce,,console_ io and other friendlier routines to run. 

To locate the RPV subsystem, f i nd_rpv_ subsystem looks in 
sys_boot_ inf o. If the data is there, it will try to boot the RPV 
subsystem firmware (if needed). If not, it queries the operator 
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for the data. If, later in ini t ial izat iorij the data should prove 
suspect (e.g. RPV label does not describe the RPV) j control 
returns here to re- query the operator. The operator is first 
asked for a command line specifying the RPV subsystem model and 
base channel J and the RPV drive model and device number. The 
operator may request that the system, generate a query in detail 
for each item. Cold boot is also requested in the 
f ind_rpv_ subsystem dialog. The simple command processor j 
bce_ command. processor. J is used to parse the "cold" and "rpv" 
request lines described above. 

The RPV data is filled into the config deck, and 
initialization continues with init_pvt and friends. 
init_root_vols is called through its early entrypoint so as to 
allow for an error return. Errors occur ing during the initing of 
the rpv will cause a re- query of the rpv data by returning to the 
call to get_io_segs. 

Firmware is booted in the RPV controller by 
boo t_rpv_ subsystem, called from find_rpv_ subsystem, which finds 
the appropriate firmware image and calls hc_load_mpc. A database 
of device models and firmware types and other configuration 
rules, conf ig_data_ . cds, is used to validate operator input and, 
for example, translate the subsystem model into a firmware 
segment name. 

ini t_roots_vols checks for the presence of and creates 
certain key partitions on the rpv. The "conf" partition, if not 
present, is created by trimming 4 pages off of the hardcore 
partition. The "bee" (bee crash handler, temporary area and MST 
storage) and "file" (boot load file system) partitions are 
created, if any is not found, by a call to create_rpv_partit ion. 
This program shuffles the disk pages to find enough contiguous 
space at the end of the disk for the partitions. 

After running establ i sh_temp_sess and f ind^f i le_part i t ion, 
the rest of the MST is read. This step is performed during the 
"early" pass or whatever is the first boot pass, 
tape. readers i n i t sets up tape reading. load_mst reads in collec- 
tion 1.2 (config deck sources and exec_ corns) into bee file system 
objects, collection 1.5 (bee paged programs and firmware images) 
into mst area pages leaving around traces for 
load_mst$ ini t_ commands (which maps them into the bee address 
space) and saves collections 2 and 3 on disk for warm booting. 
tape.readerSf inal shuts down the tape. I oad_mst$ ini t^ commands 
then runs. 

The early or the first boot pass then initializes bce.data 
references to paged objects with ini t^bceS paged. 

An early command level is now entered, using a subset of 
the real bee command level commands. This level is entered to 
allow editing of the config deck. 
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After leaving command levelj init_clock.s is called. This 
is the time when the operator sets the clock. Up until this 
tinej the times shown were random. If the operator realizes at 
this time that he must fix the config deck^ or whatever, he has a 
chance to return to the early command level. When the clock is 
set J control proceeds. 

At this point J early initialization's work is done. The 

real config deck is read in (by est ab 1 i sh_conf i g_ deck) j and the 
system can rebuild the wired databases to their real sizes. 
Interrupts are masked, completion of pending console I/O is 
awaitedj and the sit allocation pointers are restored to their 
pre- CO I lection- 1 values. Control then moves to the "boot" pass. 



The crash pass recreates a "boot" environment from which 
dumps can be taken and emergency^ shutdown can be invoked. It 
differs from the "boot" pass only in the verbosity (to avoid 
printing many messages at breakpoints) and in the command level 
that is reached. 



RE EARLY PASS 

A re_early pass is run to restore a safe environment 
following a failure to boot to the "boot" command level. It is 
identical to a "boot" pass except that it uses a saved config 
deck known to be good and reaches a "early" command level. 



&QE CRA9H EhSS. 

The bce_ crash pass is run to restore a safe environment 
following a failure to boot the " service" pass. Thismay also be 
the result of a failure of a bee utility invoked at the "boot" 
command level. This pass is identical to the boot pass except 
that i t uses a saved conf i g deck known to be good and reaches the 
"bce_ crash" command level. 



$HMT PASS 

The shut pass is run when Multics shuts down, as opposed to 
crashing. It differs from the boot pass only in that 
load_disk_mpcs is not run, because it shouldn't be ncessary 
(Multics was using the mpcs okay) and because it would interfere 
with possible auto exec_com operation. 
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Boot load Command Environment modules are not included in 
this section. 



announce chwm.pll 

The name of this program means 

announce_Core_High_Water_Mark. It will announce the extent to 
which memory is filled during the various passes of collection 1 
when the "chwm" parameter appears on the "parm" card in the 
config deck. Near the beginning of each pass^ this program 
announces the amount of memory used^ based upon information in 
the sit. At the end of service Initial izationj it walks down the 
core map entrieSj looking for pages that are available to page 
control and those that are wired. The difference between the 
memory size and the total figure given here is the amount taken 
up by non-page control pages, the sst for example. As a side 
bonusj the before entrypoint announces the usage of 
i nt_unpaged_page_ tables; the after entrypoint announces the usage 
for unpaged_page_ tables. 



boot rpv subsystem. pll 

boot„rpv_subsystem is the interface between 

f i nd_rpv_ subsystem and hc_load_mpCj the hardcore firmware loading 
utility. All that it really has to do is find the appropriate 
firmware segment in collection 1. config_data_ is used to map 
the controller model to a firmware segment name, of the usual 
(T&D) form ( f w. XXXnnn. Ymmm) . The segment and base channel are 
passed to hc_load_mpc, and the results (success or failure) are 
returned to f ind_i^pv_ subsystem. 



fc>QQt t^pg ip.pll 

This is the program that performs reading of the MST by 
collections 1 and beyond. It uses the physical record buffer as 
an i/o area. io_manager is used to perform the i/Oj with dew 
lists generated within this program. 



bootload_l is the first collection 1 program, called 
directly by collection 0. It fills in the stack headers of the 
prds and inzr_stkO to initialize the PL/1 environment. It then 
calls initial izer, pll which pushes the first stack frame. 
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collect free core. oil 



At the end of collection 1 service ini t ial izat ion^ this 
program is called to free the storage taken up by the previously 
wired initialization segments. It does this by marking all core 
map entries for pages still unpaged (Judged from the address 
field of the sdws of all segments) as wired and marking all of 
the rest as free (available for paging). It special cases 
breakpo i ntable segments to avoid freeing references to 
br eakpo i n t_ page . 



create rov part it ion. oil 

To save the effort of creating the new Boot load Multics 
partitions by requiring all sites to perform a rebuild_disk of 
their rpvj this program was created. It creates partitions on 
rpv (high end) by shuffling pages about so as to vacate the 
desired space. The pages to move are found from the vtoces. The 
vtoces are updated to show the new page location and the vol map 
is updated to show the new used pages. This program uses 
read_disk to read and write the pages. No part of the file 
system is active when this program runs. 



delete seas.Dll 

delete_segs is called after the various collections to 
delete the segments specific only to that collection (temp segs) . 
It is also called at the end of collection 3 to delete segments 
belonging to all of initialization ( init segs), It scans the ast 
list for the appropriate segments^ uses pc$truncate to free their 
pages ( in the hardcore partition) or pcScleanup to free the core 
frames for abs-segs and then threads the astes into the free 
list. This program is careful not to truncate a breakpo int_ page 
threaded onto a segment.. 



disk_reader is used by the collection 1 loader (of collec- 
tion 2) J segment. loader J and by the collection 2 loader^ 
load_systemj to read the mst area of disk. It operates by paging 
disk through di sk_mst_seg. The init entrypoint sets up 
disk_mst_seg unto the first 256 pages of the mst area to be read. 
As requests come in to read various wordSj they are paged from 
this segment. When a request comes in that is longer than what 
is left in this segmentj the remainder is placed into the 
caller's bufferj and disk_mst_seg re-mapped onto the next 256 
pages. This continues as needed. 
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establish confia deck. oil 



The config deck is stored in the "conf" partition on the 
RPV in between boot loads. It runs in one of two waySj depending 
on whether it is setting up for service or bee use. For bee use, 
a abs-seg is created which describes the disk version, 
conf ig_ deck still describes the memory version. If it is 
necessary to read in the disk versionj abs^seg is copied to 
conf ig_ deck. Likewise^ if some program ( conf i g_deck_edi t_ in 
particular) wants to update the disk version^ abs_seg is again 
usedj receiving the contents of conf ig_ deck. During service, 
conf ig_ deck is itself both wired an an abs-seg on the disk 
partition. This is done by creating an aste whose ptws describe 
memory. We make the core map entries for the pages occupied by 
conf ig_ deck describe this aste and the disk records of the conf 
partition, These erne's are threaded into page controls list 
(equivalent of freecore) providing a valid Wired segment, at the 
address of conf ig_ deck. 



fiU vol Q?<l;gnt^ tPU 

This is the ring 1 program that obtains, through the 
infamous "init_vol loop", the desired parameters of a disk to 
initialize. It is called in initialization by init_empty_root 
when performing a cold boot to determine the desired partitions 
and general layout desired for the rpv. 



find rpv subsystem. oil 

f i nd_rpv_ subsystem initializes configuration and firmware 
for the RPV disk subsystem. When available, it uses information 
in sys_ boo t_ info. When that information is not present, the 
operator is queried. The basic query is for a request line of 
the form: 

rpv Ice MPC_model RPV_model RPV_ device 

or 

cold Ice MPC_model RPV_model RPV_ device 

as described in the MOH. 

If the operator makes a mistake, or types help, the 
operator is offered the opportunity to enter into an extended, 
item by item dialog to supply the data. 

The information is checked for consistency against 
conf i g_data_ J a cds program that describes all supported devices, 
models, etc. The mpc is tested through 

hc_ load_mpe$test_control ler J to see if firmware is running in it. 

If the response is power off, then boot_rpv_ subsystem is called 
to load firmware- Then i n i t_ear ly_conf i gSdi sk is called to fill 
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this data into the config deck. If a later stage of 

initialization discovers an error that might be the result of an 

incorrect specification at this stage^ control is returned here 
to give the operator another chance. 

The operator is also allowed to enter "skip_load" or 
"skip" J as a request before entering the rpv data. This forces a 
skip of the firmware loading^ regardless of the apparent state of 
the mpc. 



g^t iQ g^g$,pn 

A scan through the config deck determines the sizes of the 
various hardcore i/o databases which this program allocates. 
This program also fills in some of the headers of these databases 
as a courtesy for later initialization programs. The key 
determiners of the sizes of the tables allocated are the number 
of subsystemsj the number of logical channels to devices^ the 
number of drivesj the number of ioms^ etc. get_main is used to 
allocate the areaSj using entries in the sit to find the memory. 
Areas allocated are: the pvtj the stock_segSj the disk_segj 
ioi.dataj iom_data and io^conf ig_data. 



get main.pll 

get_main is used to create a segment that is to reside in 
main memory. It runs in one of two waysj depending on whether 
allocation off the sit ( si t . f ree_core_start ) is allowed. When 
this is not allowed (later in initial ization) ^ 
make. sdw$ unthreaded is used to generate the segment/ aste. 
pc_absSwire_abs_cont ig forces this segment to be in memory. 
Earlier in initialization (before page control is active)^ the 
segment is allocated from the free core values in the sit. These 
values determine the placement in memory of the to be created 
segment. get_main allocates a page table for this segment in 
either i nt_unpaged_page_ tables or unpaged_page_ tables (depending 
on whether the segment will eventually be made paged). The ptws 
are filled in and an sdw made. The given_ address entrypoint of 
get.main can be used to utilize its unpaged segment page table 
generation capabilities (as in init.sst). 



he I oad mpc .oil 

hc_load_mpc embodies the protocol for loading all MpC's. 
It is an io_ manager client. Since the firmware must be in the 
low 256Kj a workspace is allocated in free_area_1 and the 
firmware image is copied out of the firmware segment and into 
this buffer for the actual I/O. The urc entrypoint is used to 
load urc mpcs. This entry accepts an array of firmware images to 
load. It scans the list to determine to which channels each 
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overlay applies. The extra entrypoint test_ control ler, used by 
f ind_rpv_ subsystem and load_di sk_mpcs, tests a controller by 
executing a request status operation. The results of this are 
used to see if the mpc seems to be running (has firmware in it). 



init aste pools. oil 

This program is called exclusively from init_sst and really 
does most of its work. It builds the four aste pools with empty 
astes appropriately threaded, Each aste is filled in with ptws 
indicating null pages. 



init clocks. pll 

This program performs the setting of the system clock. It 

starts by providing the time and asking if it is correct. If it 
iSj fine. If the operator says it's notj the operator is 
prompted for a time in the form; 

yyyy dd hh mm {ss> 

The time is repeated back in Englishj in the form "Mondayj 
November 15 1982". If the boot load memory is a SCUj the operator 
is invited to type "yes" to set this time (when the time is met), 
or "no" to enter another time. The time is set in all the 
configured memories, to support future Jumping clock error 
recovery. On 6000 SC's, the program translates times to SC 
switch settings. The program gives the operator time to set the 
clock by waiting for an input line. At any time, the operator 
may enter "abort'% realizing that something is wrong. 
init_clocks then returns. real_ initial izer will re-enter the 
early command level in this case. 



init early conf ia.pll 

i n i t_ ear I y_conf i g fabricates a config deck based on the 
information available after collection zero has completed. The 
bootload CPUj IGiM, console, and tape controller are described. 
The port number of the bootload CPU is not filled in here, since 
it is not easily determined. Instead, scs_and_clock_ ini t$ear ly 
fills it in. Appropriate parm, sst, and ted cards are 
constructed, and placeholders are filled in for the RPV 
subsystem, so that iom_data_ init will reserve enough channel 
slots. init_ear ly_conf igSdisk is used to fill in the real values 
for the RPV subsystem once they are known. 
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in it empty roo■t.Dl^ 



f i 1 l_vo\_extents_ J the subroutine used by the user ring 
init.vol commandj has been adapted to provide the main function 
of this program. It provides a request loop in which the 
operator can specify the number of vtoceSj partition layout j etc. 
The operator is provided with a default layoutj including the 
usual set of partitions and the default (2.0) average segment 
length. If it is changedj the operator is required to define at 
least the hardcore and bee required partitions and (for the 
moment) the bos partition. 



init he part.PlI 

!ni"t_hc_part builds the appropriate entries so that paging 
and allocation may be done against the hardcore partition. It 
builds a pseudo volmap C volmap_abs_seg) describing the hardcore 
partition (which is withdrawn from the beginning thereof) 
allowing withdrawing of pages from the partition. A record stock 
is also created of appropriate size for the partitions. 



init par t it ions. Pll 

This program mak.es sure that the partitions the operator 
specified in the config deck are really there. It checks the 
labels of the config deck specified disks for the specified 
partitions. Disks that do have partitions so listed are listed 
as un- demountable in their pvt entries. 



inU pyt.pll 

The pvt contains relatively static data about each disk 
drive (as opposed to dynamic information such as whether i/o is 
in progress). init_pvt sets each entry to describe a disk. No 
i/o is done at this time so logical volume informationj etc. can 
not be filled in. Each disk is presumed to be a storage system 
disk J until otherwise determined later, 



ini t_root_vols finds the disks that will be used for 
hardcore partitions. It mostly finds the disks from root cards 
and finds the hardcore partitions from the labels. For the rpVj 
it will also call i n i t_empty_rootj if a cold boot is desired^ 
call create_rpv_part i t i onj if various required partitions are 
missing (MRll automatic upgrade) j and set various pvt entries to 
describe the rpv. During the service pasSj init_hc_part is 
called to establish paging (and allow withdrawing) against the 
hardcore partition. 
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in it scu.pll 

This rou-tine is used within scas_init -to in it a given scu. 
It compares the scu configuration information (from its switches) 
with the supplied size and requirements. When called for 
boot load Multics purposes^ the size of the scu may be larger than 
that specified (generated) in the config deck without a warning 
message. It generates ptws so it can address the scu registers 
(see the description in the glossary for the seas). The execute 
interrupt mask, assignment and mask/ port assignment on the 
memories is checked here. 



in it sst.pll 

init.sst starts by determining the size of the pools. 
Normally, this is found in the sst config card (although init_sst 
will generate one of 400 150 50 20 if one isn't found). For 
early and boot load Nultics ini tial izationj though^ the pools 
sizes are determined from the current requirements given in 
figures in boot load_ inf o. The size of the core_map is determined 
from the amount of configured memory for normal operation and is 
set to describe 512K for early and bootload Multics operation. 
The area for the sst is obtained, either from the top of the 
bootload scu for normal operation, or from the sit allocation 
method for early and bootload Multics operation. The headers of 
the sst and core map are filled in. init_aste_pools actually 
threads the astes generated. The pages of memory not used in low 
order (or bootload (512k)) memory are added to the core_map as 
free. For normal operation, the other scu's pages are also added 
to the free list. col lect_free_ core will eventually add the 
various pages of initialization segments that are later deleted. 



init vol h^acjgr .pU 

ini t_empty_root uses this program to initialize the rpv. 
This routine writes out the desired label (which describes the 
partitions filled in by f i I l_vol_extents_) , generates an empty 
vol map and writes it out, and generates empty vtoces and writes 
them out. 



initial error handler.pll 

This any_other handler replaces the fault_ vector "unexpect- 
ed fault" assignments. It implements def au I t_ restart and 
quiet_restart semantics for conditions signalled with info, and 
crashes the system for all other circumstances. 
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initial ize.faults has two separate entrieSj one for setting 
things up for collection Ij and one for collections 2 and beyond. 
This description is for collection 1 

C initial i ze_ fault s$fault_ init_one) . initial i ze_f aul ts_data 

describes which faults have their fault vectors set to 
f i m$pr i iT»ary_f aul t_ entry ( scu data to pdsSf im_data) j 

f i m$si gnaT_entry (scu data to pdsSsi gnal_data) ^ 

f im$onc_ starts shut_entry (scu data to pdsSf im_data) or 
wired^f im$unexp_f ault (scu data to prpds$sys_trouble_data) (all 
others). Special cases are: lockup and timer runout faults are 
set to an entry that will effectively ignore them. Derails go to 
f im$dr l_entry to handle breakpoints and special drl traps. 
Execute faults are set to wired_f im$xec_f ault (scu data to 
prds$sys_trouble_data) . Page faults are set to pagef aul t$ fault 
(scu data to pds$page_ fault. data) . And connect faults are set to 
prdsSf ast_ conn ect_ code (scu data to prdsSf i m_data) . Write access 
is forced to certain key programs to set values within them. 
Access is reset afterwards. These are pointers which must be 
known by certain programs when there will be no mechanism for the 
programs themselves to find them. An example is the pointers 
within wired_f im specifying where scu data is to be stored. The 
last thing done is to set the signal, and sct.ptr in the 
inzr.stkO stack header so that signalling can occur in collection 
1 . 



initialize faults data.cds 

This cds segment describes which faults go to where so that 
initial ize.fau Its can so set them. For collection Ij the major 
faults set are; command and trouble to f i mSpr i mary.f aul t_ entry 
(scu data in pds$f i mudata) j access violationj stopej mme^ fault 
tag 1j 2 and 3, derail^ illegal procedure^ overflow^ divide^ 
directed faults Oj 2 and 3j mme2^ mmeO^ mme4 to f imS si gnal_ entry 
(scu data to pds$signal_data) j shutdown, op not complete and 
startup to f i m$onc_start_shut_ entry (scu data to pds$f i tn_data) 
and the rest to wired_f im$unexp_f ault (scu data to 
prds$sys_trouble_data) . 



initial izer.pll 

initializer consists of only calls to real_ initial izer, 
delete_segs$delete_segs_ ini tj and init_proc. real_ initial izer is 
the main driver for initialization. It is an init seg. 
initializer exists as a separate program from real_ init ial izer 
because, after the call to delete init segs, there must still be 
a program around that can call init_proc. This is the one. 
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init-PlI 



The function of this program is to set up the data bases 
used by io_ manager. These include iom_data and the actual 
mailboxes used in communicating with the iom. The iom cards are 
validated here. The overhead channel mailboxes are set for the 
described channels. 



load disk mpcs.pll 

During the "boot" pasSj all disk mpcs must have firmware 
loaded into them. This is done by load_di sk^mpcs. This program 
scans the conf ig deckj searching for disk mpcs. It tests each 
one (with hc_ load_mpc$test_control ler ) to determine a list of 
apparently npn- loaded disk mpcs. If this list is not emptyj it 
prints the list and asks the operator for a sub- set of these to 
load. bce_fwload is used to perform the actual loading. 



load_mst reads in the MST. It contains a routine which 
understands the format of a MST, This routine is supplied with 
various entry variables to do the right thing with the objects 
read from the various collections. For collection 1.2, the 
objects are placed into the bee file system through bootload_fs_. 
For collection 1.5, the segments have linkages combinedj etc. 
just as in segment loader. The objects are placed on disk, in 
locations recorded in a table. These are paged bee programs. 
Collections 2 and 3 are simply read in as is, scrolling down the 
mst area of the "bee" partition using the abs-seg d i sk_ mst_ seg . 
The i n i t_ commands entrypoint uses the table built while reading 
collection 1.5. The appropriate bee segments are mapped onto 
disk using the locations therein. 



mgK^, sdw , pll 

make_sdw is the master sdw/aste creation program for 
collection 1 and beyond. It contains many special cases to 
handle the myriad types of segments used and generated in 
initialization. It's first job is to determine the size of the 
desired segment. The size used is the maximum of the site's 
current length, maximum length and the size given on a tbls card 
(if the segment's name is in var iab I e_ tables) . Also, an extra 
page is added for breakpoints when needed. Given this size, an 
appropriate size aste is found and threaded into the appropriate 
list, either init segs, temp segSj or normal segs. Wired segs 
aren't threaded] they are just listed as hardcore segments. The 
page table words are initialized to null addresses. If the 
segment is wired and is breakpo i ntable, the last ptw is instead 
set to point to br eakpo i nt_ page . For abs-segs, this is the endj 
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abs segs and other "funny" segs must build their own page tables 
and a real sdw to describe them. For a normal segment^ however, 
the page table entries are filled as follows". an appropriate 
hardcore partition to hold the pages is chosen. abs_seg's sdw is 
set to indicate this null address page table. The various pages 
are touchedj causing page control to be invoked to withdraw an 
appropriate page against the hardcore partition whose drive index 
is in the aste. (abs_seg's sdw is then freed.) make. segs_ paged 
and segment. loader J the main clients of make_sdWj will then copy 
the desired data (either from wired memory or from the tape) into 
these new (pagable) pages. 



mK^ ^egg paged, pV.1 

make_segs_ paged i that most famous of initialization pro- 
gramsj actual I y^ in a way^ has most of its work performed by 
make_sdw. make_ segs_ paged examines all of the initialization 
segments, looking for those it can page C i . e. , not wired, not 
already made paged, non-abs-segs, etc.). It walks down this list 
of segments from the top of memory down, using make_sdw to 
generate an aste, an sdw, and a page table full of disk pages for 
it. The sdw is put into dseg, and the contents of the wired 
segment is copied into the paged version. The pages of memory 
are then added to page control's free pool The dseg is also 
copied with a new dbr generated to describe it. 

Breakpointable segments are special cased in two ways. 
First of all, when the pages of the old segment are freed, 
occurences of breakpo i nt_page are not. Also, when copying the 
segment, breakpoints set within it must be copied. All of 
breakpo i nt_ page cannot be copied since it includes breakpoints in 
other segments. Thus, we must copy each breakpoint, one at a 
time by hand. 



move non perm wired aeas-PlI 

This program takes the segments allocated high addresses by 
collection 0 (paged segments and in it segments that are not 
firmware segments) which were put at the top of the 51 2K early 
initialization memory, and moves them to the top of the 
contiguously addressable memory, leaving the top of the low 
controller for the sst.seg and core_map. 

This program depends on the knowledge that the loader 
assigns segment numbers in monoton i cal ly increasing order to 
permanent supervisor and init segs, and that the high segments 
are allocated from the top of memory down. Thus it can move the 
highest segment (in memory address) first, and so on, by stepping 
along the SLTE's. 
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The copying of the segment can be tricky^ though j since not 
only must the contents be moved but the page table must be 
changed to reflect the new location. For thiSj we build abs_segO 
to point to the new location. The segment is copied into 
abs_segO. We now make the sdw for the segment equal to that for 
abs_segO. The segment is now movedj but we are using the page 
table for abs_segO for it, not the one belonging to it. Soj we 
fix up the old page table to point to the new location^ and swap 
back, the old sdw. This starts using the new ptws in the old 
place. 

Segments that were breakpo i ntable (had breakpo i nt_page in 
them) must be special cased not to move the breakpoint page. 



oqcjcm ■ D 1 1 

Within i n ! t i al i zat i onj the ini t_al l_consoles entrypoint of 
ocdcm_ is called. This entrypoint sets up oc_data to a nice safe 
(empty) state. The various console specific parms are found and 
saved. The main loop examines all prph opc cards. They are 
validated (and later listed if cist is specified). For each 
console, a console entry is filled describing it. The boot load 
console, when found, is specifically assigned as boot load con- 
sole. As a last feature, the number of cpus is found. This is 
because the longest lock time (meaningful for determining 
time-outs) is a function Of the number of processors that can be 
waiting for an i/o. 

ocdcm_ also provides for bee a special function. It 
maintains wi red_hardcore_data$abort_ request, set to true whenever 
the operator hits the request key when this was not solicited (no 
read pending). This flag is used by bce_check_ abort to 
conditionally abort undesired bee operations. 



prds i nit .on 

This program simply initializes certain header variables in 
the prds. This includes inserting the f ast_connect_codej the 
processor tag, etc. 



pre link he. oil 

The linker for collection 2, this program performs a 
function analogous to that performed by bootload_ I inker . It 
walks down the linkage sections of the segments in question, 
looking for links to snap. slt_manager is used to resolve 
references to segments. A definition search is imbeded within 
this program. 
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read_disk. is the routine used to read a page from or to 
write a page to disk.. The init entry point sets up rdisk^seg as 
a one page paged abs segment for such purposes. Actual page 
reading and writing consists of using disk_ control to test the 
drive (unless the no_test entrypoints were used) ^ and then page 
control to page the page, For readSj we construct a page table 
word describing the page of disk.. Touching rdisk_seg then reads 
it in, For writing, we generate a null address page table entry. 
When we write to it, a page of tnemory is obtained. By forcing 
the core map entry to describe the desired page of disk, unwiring 
the page and performing a pcScleanup (force write), the page 
makes it to disk. 



read disk label.pll 

To read a disk label, we call read_disk_label . It uses 
read_disk to preform the i/o. Several such reads will be 
performed. if necessary. The label is validated through a 
simple check of label . Mult ics, label . versi on and 

label . time_registered. 



real i n i t i al i zer . p 11 . pmac 

real_ init ial izer is the main driver for initialization. It 
largely just calls other routines to set things up, in the proper 
order . 

There are many paths through real_ initial izer as described 
above. All paths set an any_ other handler of 

initial_error_ handler to catch unclaimed signals, which eventual- 
ly causes a crash. 

The main path through real_ in i t i al i zer calls collection_1 
(an internal subroutine) multiple times and then passes throqgh 
to collections 2 and 3. Each call to col lection_l, in the normal 
case, "increments" sys_ inf oScol Icct ion_1_phasej thus producing 
the main set of collection 1 passes. Various deviations from 
this exist. Aborting disk mpc loading resets the phase to 
re_early and branches back to the "early" command level. A 
failure when finding the rpv during the "early" pass retries the 
"early" pass. The reinitialize command resets the phase to 
"early" and then simulates the bee "boot" function, thus making 
the next pass become a n®'w "boot" pass. 

When Mult ics crashes or shuts down, the toehold restores 
the machine conditions of bee saved in the toehold. These return 
the system to save_handler_mc, which quickly returns through 
init_ toehold to real_ i n i t i al i zer . The routine collection_1 
senses this and returns to the main collection_l calling loop. 
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real_ initial izer keys off the memory_ state (determines between 
crashing and shutting down) and old_ memory. state (state of 
crashed memory - determines crashed collection 1 phase) in the 
toehold to determine the pass to run next. 

real_ i n i t i al i zer includes a stop- on- switches facility. 
pl1_macro is used to assign a unique number to each step in 
initialization. This number can also be used in the future to 
meter initialization. Before each step in init ial izat ion^ a call 
is made to the internal procedure ch©cfc_stop. If the switches 
contain "123"b3 II "PNNN"b6, where PNNN is the error number in 
binary coded decimal (P is the collection 1 phase^ NNN is the 
stop number obtained from a listing)^ bee is called (if the 
toehold is active). 



seas init.pll 

scas_init inits the seas (system controller addressing 
segment). It is the keeper of things cpu and scu. The config 
deck is searched for cpu and mem cards which are validated and 
the boxes' switches validated against the cards. The scsScow 
(connect operand words) are filled in here with values so that we 
may send connects to the various processors. init_scu is called 
to set masks and such for the various scus. The port enables are 
set for the ioms. The cpu system controller masks are checked. 
Final I y^ if the cpus and ioms do not overlap in port number Sj the 
cyclic priority switches are set on the scus. 



gnd cIoqk inU.PlI 

This program initializes most of the data In the scs. In 
previous systems^ the scs was mostly filled in its cds source. 
To support multiple i n i t i al i zat i onSj though^ the segment must be 
reset for each pass. This program also has the task of setting 
sys_ inf o$clock_ to point to the bootload SCU. Final ly^ at its 
Searly entrypoint, it fills in the bootload SCU memory port 
number in the config deckj since it used that data in scs 
initialization. Initializing the scs consists of initiating data 
about cpus and scus. 



segment loader. pll 

segment. loader is used to load collections 2.0 and beyond. 
It uses disk_reader to read records from the MST of disk. The 
various records from the MST are either collection markSj header 
records (denoting a segment) or the data forming the segments. 
Given information in the segment header j an appropriately sized 
area in wi_linkage$j ws_linkage$j ai_linkage$ or as.linkageS is 
generated. s I t_ managers bui I d_ entry chooses the next segment 
number (either supervisor of initialization) for the segment and 
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creates the sit entry. make_sdw creates an sdw an the page table 
and allocates disk space in the hardcore partition for the 
segment. With read/write access forced for this new (pagable) 
segmentj the segment is read from disk. Access is then set as 
desired in the header record. We loop in this manner until we 
encounter a collection mark when we stop. 



sit manager .Dll 

This is a relatively simple program. 

si t_ managers bu i I d_ entry looks at the header read from an MST and 
builds a sit entry. The header defines whether this is a 
supervisor or an initialization segment (which defines from which 
set of segment numbers (supervisory start at Oj initialization 
start, at, 400 .octal ) it is given), what names to add to the name 
tablej and whether this segment has a pathname which needs to be 
added to the name table (so that i n i t_branches can thread them 
into the hierarchy). While it is building the entry^ it hashes 
the names in the same manner as boot I oad_s I t_ manager . 
si t_ manager* get_seg_ptr uses this hash list to search for the 
segment name requested. 



sys jinfo,Pd^ 

sys_info is described under data bases. 



■<vapg re^dQr.p\1 

tape_reader uses boot_tape_io to read MST 
is capable of reading several tape records and 
a user supplied buffer. It validates the tape 
for Mult ics-nesSj performing the (old) reading 
error recovery mechanism. 



tc_init is run in two parts, the second called part_2 run 
in collection 2. Part one, just called tc^init, allocates an 
appropriately sized tc_data (see the description of 
tc_data_header, above) given the supplied number of aptes and itt 
entries. The workclass entries are initialized to their 
defaults, Workclass 0 is set up for the initializer as realtime, 
etc. Everyone else is put initially into workclass 1. The aptes 
and itts are threaded into empty lists. Initial scheduling 
parameters are obtained from the schd card. The length of the 
prds is set (either default or from tbls card). The stack_0_data 
segment (which keeps track of the ring 0 stacks given to 
processes when they gain eligibility) is initialized. Apte 
entries for the initializer and idle (bootload cpu) are created. 



tape records. It 
packing them into 
records i t reads 
re- written record 
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Final I memory is allocated for the pds and dseg of the various 
idle processes (which won't actually be started until 
tc_ ini t$part_2) . 
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SECT I ©N 4 



THE BOOTL0AD COMMAND ENVIRONMENT 



Bool load Multics must provide a certain number of 
facilities when the storage system is not available. Examples 

are system dumps to diskj disk saves and restores , interactive 
hardcore debug (patch and dump) j and automatic crash recovery. 



INITIALIZATION 

There are two ways that the command environment is entered. 
When an existing system is booted from power-up (cool boot)j the 
command environment is entered to allow conf ig deck maintenance 
and the like. When the service system crashes^ the command 
environment becomes the crash recovery environment that oversees 
dumping and automatic restart. A full cold boot is a special 
case of a cool boot. 

The heart of the boot load Multics command environment (bee) 
runs mostly wired. The paged segments are paged temp segmentSj 
managed by get_t©mp_ segments and friendSj for such purposes as 
qedx buffers and active function expansion. The bee file system 
is paged. Alsoj some bee command programs are pagedj through the 
grace of load_mst. These are mapped onto an area of the bee 
partition. bee does not use the storage system, nor the hardcore 
partition. 

Certain special programs are run so as to initialize bee. 
These are: init_bce to enable the basic facilities of switches 
and areas and such; f ind_f i le_partit ion to enable the bootload 
Multics file system; establ i sh_temp_segs to provide paged temp 
segments; and^ I oad_ mst$ i n i t_ commands to allow references to 
paged bee programs. load_mst was described under the bootload 
Multics initialization pass in collection 1. 



ENVIPQNMENT tm. FAQlLHIEg.. 

The basic facilities of the command environment are: 
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a free area. free_area_l is ini'tial ized with def ine_area_j 
and a pointer left in stack._header , user_f ree_area and 
stack_ header . system_free_areaj so that allocate statements 
with no "in" qualifiers work. get_system_f ree_area„ () will 
return a pointer to this area. This area is used for global 
data needed between commands. Each command normally finds 
its own local area, normally on a paged temp segment. 

* standard input j output and error entries that hide the 
distinction between console and "exec_com" input. These are 
entry variables in the cds program bce.data. cds, They are 
hardly ever called directlyj as more sophisticated 
interfaces are defined atop them. The entry variables are 
bce_data$get_ I inoj bce_data$put_ chars and 
bce_data$error_put_ chars. get_chars is not sensible in the 
console environment, for the console will not transmit a 
partial line. The module bce_console_ io is the usual target 
of the entry variables. It uses ocdcm_j oc_trans_ input_ and 
oc_trans_output_ . bce_data also contains the pointers 
get_ I ine_data_ptr, put_chars_data_ptr and 
error_put_chars_data_ptr which point to control information 
needed by the target of the entry variable. The pair of 
values of an entry variable followed by the data pointer is 
what constitutes a bee switch. A pointer to this switch is 
passed around much as an iocb pointer is passed around in 
Mult i OS. Both ioa_ and formline_ understand these bee 
switches so that normal calls may be rpade. 

* bce_query and bce_query$yes_no. Each takes a response 
argument^ ioa_ control stringj and arguments, and asks the 
question on the console. An active function interface is 
provided. 

« bce_ error is the local surrogate for com_err_j used by 
various non command level programs. It does not signal any 
conditions in its current implementation. com_err_ and 
act i ve_f nc„err_ simply call bce_error appropriately when in 
bee. 

* a command processor. The standard command_ processor _ is 
used to provide a ssu_-like subsystem facility. The various 
command programs are called with a pointer to 
bce_ subsystem. info_ J of which the arg_list_ptr is the impor- 
tant information. 

* a request line processor. Any program that wants to parse 
lines using standard syntax (without quotes, parentheses, or 
active functions, for now) calls bce_command_processor_ with 
the command line, a procedure that will find the command, 
and a return code. f i nd_rpv_ subsystem, for example, calls 
it with an internal procedure that checks that the command 
is either "rpv", "cold", "help", or "?", and returns the 
appropriate internal procedure to process the command. 
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These procedures use the usual cu_ entrypoints to access 
their arguments. 

* The paged temp segments boot load_temp_l . . bootload_temp_N. 
These are each of 128/N pages long^ and mapped as abs-seg's 
onto a part of the bee partition. N is established by the 
number of such segments 1 i sted i n the MST header ( and 
computed by establ ish_temp_segs) . These segments are 
managed by get_temp_ segments, and friends. 

* A primitive file system. bootload_fs_ manages a simple file 
system mapped onto the "file" partition on the rpv. This 
file system can hold config files or exec_ corns. It is 
writable from within Multics service. The objects in the 
file system have a max length of 128/N pageSj matching that 
of the temp segmentSj and have a single name. 

« The standard active function set. 

« Disk i/o facilities. Several exist. Some utilities call 
(read write)_disk. If they do not need the disk, test that 
this routine performs (as when accessing the (already) 
trusted rpv) j they call the no_test versions of these 
entrypoints. Another mechanism is to build a paged segment 
onto the desired disk, area^ normally via map_onto_di sk. 
This mechanism trusts the built in mechanisms of page 
control (and traffic control disk polling) to ensure that 
the i/o is noticed. A final mechanism is to call 
dctlSboot load_( read writeJj which allows the queue ing of 
multiple i/os to different disks. This is used for high 
volume operations, such as pack copying. 



PESTRJCTigNS 

Various Multics facllties are not present, within bee. Some 
are listed below. 

« No operations upon the file system hierarchy are allowed 
(except for indirect references by bce_probe to segments in 
the Multics image). 

* Normal segment truncation/ deletion/ creation is not allowed. 
The ptws must be manually freed. 

* Segments may not be grown (no withdrawing of pages is 
allowed). They must be explicitly mapped onto the desired 
free area of disk or memory. 

* No iox_ operations are allowed. Pseudo- iocb' s do existj 
though. 



4-3 



AN70-01 



* Only a finite (and small) number of paged/wired work, areas 
can exist. They also have comparatively small lengths. 

« Dynamic linking is not done. References to object names are 
done with si t_ managers get_seg_ptr . 

* Wakeups and waiting for wakeups can not be done. A program 
must loop waiting for status or use pxss facilities. 

* Timers (cput and alrm) may not be set. Programs must loop 
waiting for the time, 

* There are no ips signals so no masking is involved. The 
real question is the masking of interrupts ( pmut$set_mask) . 

* Any routine that itself 4 or through a subsidiary routine, 
calls bce_check_ abort (which includes any output operation) j 
must be prepared to be aborted at these times. ThuSj they 
must have a pending cleanup handler at these timeSj or 
simply have nothing that needs to be cleaned up. 



MODULE DESCRIPTIONS 



bee abs seg .oil 

This relatively uninteresting program maintains a list of 
abs-segs built during an initialization pass. This is done so 
that real_ initial izer can free them, en masse, when it needs to 
reinitialize before another pass. 



bee alert. pll 

Console alert messages (mostly for bee exec_;Gom' s) are 
produced by bce_ alert. It simply appends its arguments, 
separated by a space) into one string which it prints through 
bce_data$console_alert_put_ chars, This prints the message with 
audible alarm. 



bee aim die. aim 

bce_alm_die wipes out the bee toehold and enters a "dis" 

state. 



bee appending s imulat i on . oil 

All references to absolute and virtual addresses within the 
saved Multics image are performed by bce_ append ing_ simulation. 
It has multiple entrypoints for its functions. 
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The "init" entrypoint must be called before all others. It 
initializes certain purely internal variableSj for later effi- 
ciency. As an added bonusj it sets the initial dbr for the 
appending simulation based on whether it is desired to examine 
the crash image or bee itself. 

The entrypoint "new_dbr" sets a new dbr for the simulation. 
This entrypoint takes apart the dbr supplied. The main purpose 
of this entrypoint is to find this new address space's dsegj so 
it can evaluate virtual addresses. This fetching of the descrip- 
tion Caste/ page table/sdw) of dseg can be done using the absolute 
fetching routines of bce_ appending. simulation and by manually 
disecting sdws and ptws. This entrypoint must also find the 
core_mapj if presentj which is needed by the virtual entrypoints 
to find out-of -servi ce pages. 

The "(get put) absolute virtual)" address entrypoints 
actually perform the fetching or patching of data. They take the 
input address and fetch or replace data in pieceSj keeping each 
piece within a page. This is done because different pages 
desired may reside in totally different locations. 

"get_ absolute" and "put_ absolute" work in relatively simple 
ways. They examine the address to determine its location. Some 
low memory pages will be in the image on disk and fetched through 
the paged abs-segs multics_(low high)_mem. Other pages are in 
memory (above 512k). These are fetched through the abs-seg 
abs.segO which this program slides onto a 256k block as needed. 
References to absolute locations in examine- bee mode always use 
the abs_segO approach to fetch everything from memory. These 
entries keep a page_f aul t_error handler to catch disk errors^ a 
store handler to handle memory addreses not enabled at the 
processor ports and an op_not_ complete handler to catch refernces 
to scu's who have our processor disabled. 

Before virtual addresses may be fetched/ pat chedj the 
" new_ segment" entrypoint must be called. The purpose of this 
entrypoint is to fetch the sdw/aste/page table for the segment 
for later ease of reference. This is done by using the 
" get_ virtual" entrypointj referencing dseg data given the previ- 
ously discovered description of dseg (in the "new_dbr" 
entrypoint). For efficiency in fetching the sdw (meaningful for 
the dump command which calls this entrypoint for every segment 
number valid in a process and ends up fetching null sdws) j a dseg 
page is kept internal to this routine. 

Virtual addresses are manipulated by the "(get 
put) .virtual" entrypoints. These entrypoints break apart the 
request into blocks that fit into pages. For each page of the 
segment that it needSj it examines its ptw (found in the segment 
description found and provided by the " new_segment" entrypoint) 
to determine its location. Pages flagged as in memory are 
obtained by the absolute entrypoint. Pages on disk can be easily 
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manipulated by mapping rclisK._S€g onto the page and paging it. If 
it is in neither catagories, something is either wrong or the 
page is out of service. For out of service pages (pages with i/o 
in progress upon them) ^ the "correct" page is found (the page at 
the source of the i/o) and this manipulated. If this is a put 
operation^ it is necessary to replace this page in both locations 
(both memory and the disk page in use) to make sure that the 
effect is felt. AlsOj for any put operation^ the proper page 
table word must have its modified bit set so page control notices 
the modification. 



bee check abort .pII 

bce_check_ abort contains the logic for possibly aborting 
bee functions upon operator request. When called^ it checks 
wired_hardcore_data$abort_requestj which is set by ocdcm_ whenev- 
er an unsolicited request is hit. If this bit is setj 
bce_check_ abort prompts the operator with "Abort?" to which the 
response determines the degree of abort. Both this query and the 
response i/o are performed through bce_data$conso I e_C whatever] to 
force them to appear on the console. A response of "no" simply 
returns. "yes" and "request" signals sub_request_abort_ j which 
is intercepted by the bce_exec_com_ and bce_listen_j or by a bee 
subsystem. Entering "command" signals request_abort_j handled by 
bce_exec_com_ and bce_listen_ to abort a subsystem. Entering 
"all" performs a non-local goto to <sub-sys inf o> . abort_ label, 
which returns to bce^listen_ at top level. 

bce_check_ abort is called on the output side of 
bce_console_ io and other output oriented bee i/o modules. Thus, 
most operations will notice quickly the operator's intent to 
abort. However J any program that can enter an infinite 
computational loop (such as the exex_com processor trying to 
follow an infinite &goto ... &label loop) must call 
bce_check_abort within the loop to provide a way out. 



bee cofnmgincl prpQ^ggpr ,pn 

This routine is a scaled down version of 
command. processor. . It does not support active functions or 
iteration sets. Written as suchj it does not need the various 
work areas that command_processor_ needs and can run completely 
wired. It separates the command line into the usual tokenSj 
forming an argument list of the various argument strings. It 
uses a routine supplied in its call to find an entry variable to 
perform the command found. It is used in various very early 
initialization programs like init_clocks and f i nd_rpv_ subsystem 
(which obviously cannot page) as well as some boot load Multies 
programs that can deal with the simplicity and wish not to power 
up command. pr ocessor_ . 
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bce_console_ i o is the interface to the console dim ocdcm_ . 
Its function is to perform translation appropriate to the console 
( oc_trans_ input_ and oc_trans_ output.) and to call 
ocdcm_$pr i or i ty_ i o to perform the i/o. bce_console_ i o$get_ I i ne 
is the routine normally found in the entry variable 
bce_data$get_ I i ne and bce_console_ i o$put_chars is the routine 
normally found in bce_data$ put. chars and 

bce_ dat er r or _ put_ char s . 



bce_continue restarts the interrupted image. It flushes 
memory and uses prnut$special_bce_return to invoke the toehold. 
As it passes^ it resets all rtb flags in the flagbox except 
ssenb. This is so that the next return to bee does not show the 
current rtb flags. 

Also present in this module is the bos command^ which 
flushes memory and uses pmut$special_bce_return to invoke the BOS 
toehold. 



bee d ata . cds 

This cds segment contains data pertinent to the command 
environment activities of bee. It holds the entry and data 
pointers used to perform i/o on the pseudo switches 
bce_data$get. I inej bce_data$put^eharsj bce_data$error_put_ chars 
and bce_data$exec_com_get_ I ine. It keeps track of the current 
exec_com I eve I j through bce_data$command_abs_data_ptr (part of 
the exec_comLget_ I i ne switch). It also holds the top level 
subsystem info for the command level in bce_datai$subsys_ inf o_ptr . 



bpg djg-pll 

This module just checks to see if it is okay to diej which 
is actually performed by bce_alm.die. 



bee display instruction .pH 

One of the bee_probe support utilitiesj 

bce_d isp I ay_ instruct ion_ displays one (possibly multi-word) 
instruction. It uses op_ mnemonic, for its information. The 
result is to print an instruction and to return the number of 
words dumped. 
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bce_ d i sp I ay_ scu_ is another bc€_ probe utility. It displays 
the scu data found in machine conditions supplied to it. 
bce_ disp I ay_ instruction. is used to interpret the instruction 
words from the data. 



bee dumD.Dll 

The disk dumping facility of bee is found in bce_dump. It 
is actually a rather simple program but with a few tricky special 
decisions made within it. After parsing the command line 
arguments^ it figures out the process and segment options to use. 
These options are merged together in a hierarchical fashionj that 
iSj options applying to all processes apply to eligible; all that 
apply to elgible apply to running^ etc. The dump header is 
filled in with machine state information from the toehold. The 
dump header on disk is flagged as invalid. An abs-seg (dump.seg^ 
created by establ ish_temp_segs) is built to run down the dump 
partition during segment placing. Given this out of the wayj 
dumping can start. Each apte is read from the saved image 
(through bce_appending_simulat ion) . For eachj the segment 
options applying to each are determined. Given the segment 
limits in the dbr for this process^ each segment is examined to 
see if it meets the segment options. Most of the options are 
self-explanatory. When it comes to dumping non-hardcore seg- 
mentSj though, it is desired to dump any hierarchy segment only 
once. This is done by keeping a pseudo bit- map of the sst, where 
each bit says that a segment has been dumped. (Since the 
smallest possible aste in the sst is 16 words, there can be at 
most 256K/16 astes. Given an address within the sst from a 
segments' sdWj we assume that any aste that crosses the mod 16 
boundary near this address describes the same segment as this and 
need not be dumped again. ) If a segment is to be dumped^ we read 
pages from its end, looking for the first non-null page. All 
pages from the beginning of the segment up to and including this 
page are appended to the dump. (The dump.seg abs-seg is adjusted 
to indicate these pages.) When all is dumped, we update the 
header and write it out. 



bee error .pll 

A simplified form of com_ err_, bce_ error simply fetches the 
text of an error message from error_table_ and constructs an 
error message which is printed through bce_data$error_put_ chars. 
The com_ err entrypoimt is used to format a com_ err„ style 
message^ used by corn. err. when called during initialization. 
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An emergency shutdown of Multics is initiated by bce_esd. 
It uses bce^continuG to invoke the toehold to restart the image. 
However J before doing thiSj it patches the machine conditions in 
the toehold to force the image to transfer to 
emergency_shutdownl 0, to perform an esd. 



bee exec com . p 11 

bce_©xec_com_j along with bce_exec_com_ i nputj form the bee 
equivalent of version 1 exec_com's. bce_exec_com_ is a merging 
of functions found in exec_com with those found in 
abs_ i o_$ attach. It finds the ec and builds an appropriate 
ec_ info and abs_data structure to describe it. The ec attachment 
is made ( bce_data$exec_com_get_ I ine) is made to refer to this ec 
invocation J after saving the previous level. Commands are read 
from the ec through bce_ ex ec_com_ input and executed through 
command_processor_$subsys_execute_ I ine. Once bce_exec_com_ inf o 
returns a code for end of file, the ec attachment is reverted. 



bee exec com input. oil 

bce_exec_.com_ i nput performs the parsing of exec_coms. It 
is a pseudo i/o module, in the style of bce_console_ io$get_ I ine. 
It is called in two possible cases. The first is to fetch a 
command line for execution by bce_exec_com_ . In this case, the 
switch is bce_data$exec_com_get_ I ine. When an Sattach appears in 
an ec, bce_ ex ec_com_ input will have attached itself (by making 
bce_ dataS get_ I i ne point to itself) and then calls to 
bce_data$get_ I i ne will call bce_ ex ec_com_ input for a line where 
the switch ( bce„data$get_ I i ne) will point to the abs^data for the 
ec that performed the Sattach. The basic code is stolen from 
abs_ i o_ vl_get_ I i ne_ . The major changes are to delete 
non- meaningful operations like &ec_dir. 



bee execute command .pII 

This routine is the caller for the various bee command 
programs. It is passed as an argument to, and is called, from 
command_proc€ssor_$subsys_execute_ I i ne. It is given a pointer to 
an argument list generated by commandL processor as well as the 
request name. bce_ execute. command_ uses bce_map_over_requests_ 
to scan through bce_request_table_ to find the entry to call. It 
understands the difference in calling between Multics routines 
(like active functions stolen from Multics) and bee routines. It 
also understands the flags indicating within which command levels 
a command is valid. 
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bee fwload.Dll 



Firmware is loaded into various mpcs by bce_fwload. Its 
objective is to findj for each mpc desired^ the set of firmware 
images needed for it. hc_load_mpc does the actual loading. For 
a normal (diskj tape) mpcj this involves just finding the mpc 
card which shows the model. The model implies the firmware 
module needed (conf ig_data_$ mpc_x_ names. fw_ tag) . The desired 
module is found through slt_manager. (Firmware images for disk, 
were part of collection 1 and are wired (they needed to be in 
memory to be able to load the rpv controller); other images were 
part of paged collection 1.5.) For urc controllers, the main 
firmware can also be derived from the mpc's mpc card. However, 
it is necessary to check, all prph cards to find peripherals 
accessible through that urc. For each, and depending on the urc 
channel it is attached to, the appropriate firmware overlay is 
found and put in the correct slot in the list of firmware to 
load. 



\?QQ q^t f lgigl?o?<,pn 

This module performs the bee (get set)_flagbox 
commands/ act i ve functions. It is basically a version of the 
corresponding Multics routine, modified to make direct references 
to the flagbox instead of a gated access. 



qgt t^Q ppmmgn^ ^^v^i.pll 

The routine to get from real^ initial izer into command level 
is bce_ get_ to_ command_ I eve I . It builds a bce_subsystem_ inf o_ 
structure which it passes to bce_listen_. It examines the 
current state to determine if the initial command should be null 
(manual entry), the flagbox bee command (normal) or probe 
(breakpoint entry). Since it is the routine below 
real_ initial izer on the stack, it is the routine to which control 
must return so that real_ initial izer can be returned to to 
perform boot and re_ initial ize functions. Thus, boot and 
re_ initial ize are entrypoints within this program. re_ initial ize 
just returns, setting the col I actional _ phase to "early" so that 
real_ i n i t i al i zer will end up running another boot pass. This 
will cause boot load Multics to pick up any changes that have been 
made to the conf ig_ deck. boot scans the arguments which are 
inserted into the intk card. It then returns. 



bee inst length .pII 

Another bce_probe utility. This routine is used to deter- 
mine the length of an instruction, so that it may be correctly 
relocated. It differs from the real probe's version in that it 
does not attempt to deal with xec instructions. 
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bee list requests .dU 



This program implements the \ i st_requests < Ir) bootload 
Multics command. It does a simple minded walk down the bootload 
Multics request table^ using bce_map_over_requests_ j with a 
printing routine to print the request names and the description 
within the table. It understands the dont_list flagj as well as 
understanding flags indicating at which levels a given command is 
val id. 



{?CP Ugl^gn .Pll 

bce.listen is a simple loop that reads a command line from 
bce_data$get_ I i ne and executes it through command. processor, 
(using bce_execute_i command, to actually execute the request). It 
contains the sub_rGquest_.abort_ and request. abort, handlers to 
work with the operation of bce_ check. abort. 



jpQG m^P 9vgr rgg^e^t? .pH 

Programs that wish to walk down the bootload Multics 
request table ( bce_ I i st_ requests, and bee. execute. command. ) call 
bee. map. over. requests, with a routine that is called on each 
entry in the table. As suchj the format of the table itself is 
known only to this routine. 



bee name to seanum .pII 

This bce.probe utility maps segment numbers to names. It 
searches the sit and name. tables from the saved image. 
Entrypoints exists to convert a segment number to a hardcore 
segment name Cbce.segnum.to.name.) j a segment pointer to a 
v i rtual Dsme ( bce_segptr.to.name_.) , and s segment name to a 
segment number ( bce.name.to.segnum.) . 



bee probe .oil. omac 

The main portion of bee's probe support j bce.probe contains 
the main drivers for most of probe's facilities. It contains the 
request line parser, address and value parsers and most of the 
functional routines. 

bce.probe starts by examining its arguments and its envi- 
ronment to determine its operating mode. It defaults to 
examining the breakpoint image if the flagbox indicates a breakj 
to examining the crash image, when at bee. crash or crash command 
levels or to examining bee otherwise. Given its operating mode, 
it initializes the appending simulation package accordingly and 
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establishes a few initial constants. If in break modej it 
determines the point of break for operator information. 

bee proceeds to read request lines from the console. The 
first "string" in the line (or partial line leftj if this is a 
multiple request line) found by internal routine get_ string 
becomes the request name. This is looked up in a table and 
dispatched through a "case" statement. 



REQUEST ROUTINES 



The before request finds the desired address. It is 
validated to ensure that it is virtual and that the segment named 
is breakpointable, Finding the breakpoint page for this segmentj 
this request looks for an empty break slot. The original 
instruction is relocated there ( bce_r el ocate^ instruct ion_) and 
replaced by a transfer to the break block. The break block 
consists of a "drl -1" instruction, which causes the break, 
followed by the relocated instruct ion^ followed by a transfer 
back to just after the original instruction in the code. This 
break block and the transfer to the block are patched into the 
segment such that failure at any time will not damage the 
segment. 

The continue request validates itself and calls 
bce_ continue. 

The dbr request fetches its arguments. Constructing a new 
dbrj it calls internal routine new^dbr. 

The display request gets and validates its arguments. It 
loops, fetching (through bce_probe„f etch_ ) at most a page at a 
time to display (since we only allocate a one page buffer for the 
fetch). The internal routine "display" displays the data in the 
specified mode. Since data to be displayed may cross page 
boundaries, any data "display" cannot display (because it would 
need data from the next page to fill out a line) is "scrolled" in 
front of the page buffer and a new page worth's of data fetched. 
This continues until the last page is fetched. 

The let request finds the address and sets up for patching 
of same. It then loops, finding values from the request line, 
converting them to binary. These are appended unto a word based 
buffer. V^hen all are fetched, they are patched into place. 

The I i st_requests request simple prints a canned list of 
requests. 

The mc request gets its address and uses bce_ d i sp I ay„ scu_ . 

The name request uses bce_segnum_to_name_ . 
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The proc request fetches the desired apte from tc_data in 
the image. A new dbr value found therein is passed to internal 
rout i ne " nevf_dbr" . 

The quit request quits. 

The reset request performs the inverse of the before 
request. After validating its address (for virtualnesSj 
break-po i ntabi I i tyj etc. ) , it undoes the effect of before, in 
reverse order to prevent damage to the segment. 

The segno request uses bce_name_to_segnum_ . 

The stack, request validates its argument. Given the word 
offset there iHj it decides whether to start from the specified 
stack Jheader or frame, The needed data is fetched and displayed 
in interpreted form. Each stack, pointer fetched is validated, 
not only to insure that it is a valid pointer, but to insure that 
stack frame loops do not cause bee probe loops. 

The status request uses the internal routine "status" to 
display breakpoints set. It simply validates its argument and 
decides between listing breakpoints for a segment versus listing 
breakpointed segments. 



INTERNAL ROUTINES 



check_no_more_args insures that no more arguments appear on 
the request line; that is, that we are looking at a semi-colon or 
new- I ine. 

display displays data in a specified mode. It determines 
the bit sizes to display, alignments, etc. Its only trick is 
when processing the end of a buffer full that doesn't fill a 
display line. This causes it to not finish its display. Its 
caller (the display request) then appends what was not displayed 
to the front of the next buffer full so that it may appear in the 
next group. 

function is used to parse functional references, such as 
"reg(rair)". function extracts the arguments to the function 
(whose identity was determined by its caller), builds an argument 
list from these strings, and calls the function. 

get_address contains the logic to parse a bee probe 
address. It fills in the structure, bce_probe_datai$ address to 
define the current address. It special cases the dot (".") 
forms, checks for virtual forms (those with a "i" in them), 
notices absolute addresses (single octal number) and uses func- 
tion for the pseudo-var i able type of addresses (reg and disk). 



4-13 



AN70-01 



Internal routines to get_addresSj called by function^ build the 
address structure for these types. 

get_string finds the next "string" in the request line, 
Its basic Job is to pass whitespace and find string delimiters. 

get_value finds a let request value. It looks for asci i 
strings (values starting with a quote character) j which it must 
parse separately (since quoted strings confuse the notion of 
string contained in get_string), finds virtual pointers (strings 
containing "1"), and finds the various numeric types. 

line_error is used to print error messages. Besides 

printing the given messagej optionally with or without the 

current request line arg or error code^ it also aborts the 
current request line. 

new_dbr is the counterpart to the new_dbr entrypoint to the 
appending package. It exists to set up references to a few 
popular segments (sit and name.table) whenever the dbr changes. 

pass_white passes whitespace. 

status displays breakpoint status, 
zeroed when not in use it is possible to 
any segment listed in the image's sit as 
status fetches the last page (that which 
and examines each break block, 
or i gi nal_ i nstr^ptr are displayed. 



fc)ge probe datg.cds 

Information communicated between probe and its support 
routines is done so through bce_probe_data. This cds contains 
the current value of "." (current address) j as wel I as pointers 
to bce_appendi ng_seg_ i nf o structures describing key segments in 
the image used by the support routines. 



bee probe fetch .dII 

This support utility to bce_probe fetches data^ given a 
length and the current address (in bce_probe_datai$address) , It 
simply uses bce_appendi ng_s i mu I at i on for absolute and virtual 
address and read_disk for disk addresses. Register addresses 
must be specially handled by the caller. 



bee query 

bce_ query is a simple-minded counterpart to command.. query_ . 
It uses bce_datai$put_ chars to print a question and 



Since break blocks are 
find them easily. For 
being breakpointable^ 
holds the breakpoints) 
Any wi th a val i d 
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bce_data$get^ I i ne to read an answer, The main entrypoint accepts 
any answer and bce_query$yes_no accepts only yes or no which it 
returns as a bit. This routine is called with no prompt by some 
routines who find its return result (char («)) to be better that 
the buffer and length and return length returned by 
bce_ dataS get_ line. 



bee ready. pll 

bce_ready prints the bee ready message: 

bee CBCE_COMMAND_ LEVEL) TIME: 

It has a nnl entrypoint to print the message without new- line (as 
a prompt) J The normal entry prints the line (for ready message 
within exec_com) . 



bee relocate instruction .oil 

This is another support routine for bce_probe. It differs 
from the standard Multics version in that it does not allow 
relocation of "xec" instructions. (Service probe allows this by 
attempting to examine the target of the xeCj something bce_ probe 
does not attempt. ) 



bee request table .aim 

The bootload Multics request table is a normal ssu_ request 
table built with ssu_request_macros. Each entry contains a 
pointer to the routine that performs a request^ the name and 
short name of the request j and a short description of the 
request. The actual threading of the entries is known only to 
bce_map_over^requests_j which performs the walking down of this 
table. The last three flags in each rq^data entry is used to 
specify whether the command is valid at the three main bee 
command level types: earlyj boot and crash. 



This is the bee counterpart to the Multics severity 
command/ act i ve function. It does not work as the Multics routine 
doeSj however. Insteadj it knows the set of programs that 
recognize a severity indicator. For the desired one^ it calls 
the severity entrypoint thereof to find the severity. 
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bee shu^down state .dII 



The current shutdown state of the storage system Crpv 
label . shutdown. state) is found by this routine. It uses 
read_disk to find this information. 



bee state. Pll 

This command/ act i ve function simply returns the name of the 
current bee state. 



boot I pad disk taost.pll 

This routine is used in conjunction with the high volume 
disk facility of bee (dctl$bootload_(read write)). Whenever a 
disk i/o queued through this means is posted for completionj it 
is done so through bootload_disk_postj called by either dctl or 
disk_ control . The result is posted in a structure described by 
boot I oad_post_ area, incl.pll. This area must be maintained by the 
cal ler . 



boot load fs .oil 

bootload_fs_ contains various routines to act upon the 
bootload Multics file system. The format of the bootload Multics 
file system is known only to this program. The file system Is 
kept in a single abs-seg ( boot load_f i le^part i t i on) , mapped (and 
paged) off the bee partition on the rpv. A two page header at 
the start of the partition contains a directory of 174 entries 
(max that fits) listing the namej size and placement of the file 
within the segment. Also present is a free block map. Files are 
allocated as a contiguous series of blocks (64 word blocks) 
within the segment. The segment is automatically compacted by 
this routine when necessary, Entrypoints to this routine are: 
lookup (find the length of a file given its name) j list 
(allocates a list of file names and sizes within a user supplied 
area) J get (copies a file into a user supplied buffer) j get_ptr 
(returns a pointer and length to a given file ( hcs_$ in i t i ate? ) ) j 
put (allocates area v/ithin the file system for a file and copies 
a user supplied buffer into it)j put_ptr (allocates an area 
within the file system large enough for a given file and returns 
a pointer to it) (both put and put_ptr take an argument allowing 
for the deletion of a file with the same name as the one 
desired) J delete (deletes a directory entry and frees the space 
used) J rename (renames a file (does not allow name dupl ication) ) j 
and init (clear out the bootload file system entirely). 
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boot load fs cmds .dII 



This program simply calls bootload_fs_ to perform the 
functions of the boot load Multics commands printj listj deletej 
rename^ and initialize. This routine supports the star and equal 
conventions for most of its operations through match„star_name_ 
and get_equal„name_ . 



boot load_qedx is a modified version of qedx. it differs in 
its use of file system operations ( bootload_f s_) and its use of 
temp segs. 

confia deck data . cds 

The config deck editor's source of config card descriptions 
is found in conf ig_deck_data_ . This cds provides labels for the 
fieldSj numbers and types of fieldSj etc. 



confia deck edit .pH 

This is the program that edits config decks, It calls 
qedx_ to perform text editing^ specifying the cal ler_does_ i o 
option. With this optionj qedx_ calls conf i gLdeck_edi t_ to 
perform read and write operations on buffers. Any read/ write not 
to the config deck uses boot load_f s_ . Reads/writes to < config 
deck> (buffer 0) use the config deck conversion routines. This 
program makes use of conf i g_deck_ par se_j the routine that can 
convert from asci i Cpossibly labeled) form to and from binary 
form. The conversions are performed using a set of tables 
(conf ig_deck_data_) that describe the names of the fields^ the 
required and optional number thereof j the data types of the 
fieldSj etc. Also allowed by the conversion routines are cards 
of types not recognizable starting with a dot (.) which are not 
validated. This is to allow for future expansion and site 
formatted cards. 

When a command line argument is suppliedj the file 
specified is accessed ( bootload_f s_$get_ptr ) and the object 
obtained is supplied to the internal routine wr it e_ conf ig_ deck 
which sets this new deck. 



Whenever bee needs (paged) temp segments^ it calls 
get_ temp_ segment s_ . get_temp_segments_ gets these segments from 
the pool of segments boot load_temp_1 . . N. establ i sh_temp_segs 
divides the temp seg pages allocated in the bee partition (128 
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pages) up into the N segments (N is determined from the number of 
such segments listed in the mst header). The paged segments are 
built as abs-seg's onto this area of the determined length. This 
size is saved in sys_ inf o$bce_max_seg_size, establ i sh_temp_segs 
also creates the bee segments multics_(low high)_memj used to 
access the saved image^ dump_segj used to access the dump 
partition and disk._conf i g_decka used to access the rpv (real?) 
copy of the config«.deck (as opposed to our running copy in 
conf ig^deck) . 



find file partition. pH 

f ind_f i le_part 1 t ion maps the boot load Multics file system 
abs-seg ( boot load_f i le_part i t i on) onto the bee partition on the 
rpv in much the same manner as establ ish_conf ig^ deck maps the 
config deck. It also calls bootload_f s_S init to begin accessing 
the segment. If bootload_fs_ states that the file system is badj 
f ind_f i le_parti tion will call bootload_f s_$ ini t again^ this time 
to clear out the file system. 



init bce.pll 

init_bce initializes the boot load Multics command environ- 
ment features required for future programs. It is called early 
in initialization. At its wired entrypoint, it sets up 
free_area_1 as an areaj setting the inzr_stkO stack header to 
point to it so that allocates without an area work correctly and 
so that get_system_f ree_area_ also works. This routine also 
initially sets bce_dataSget_ I i nej bce_data$put_ chars and 
bce_data$error_put_ chars to their appropriate entry values 
( bce_console_ ioSget_ 1 inej bce_console_ io$put_chars and 

bce_console_ io$put_chars, respectively) so that calls to 
bce_queryj bce_ error and especially ioa_j will work. At its 
paged entrypoint^ it finishes up references to paged objed^i in 
particular J to the exec_com routines. 
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SECTION 5 



CRASH HANDLING 



Boot load Multics must be able to save the salient state of 
a crashing system and set up the command environment for dumping 
and other intervention. 



gmX PRA^HES 

Crashes in collection 0 or the early initialization pass of 
collection one should be very rare. Since the system uses a 
generated conf ig deck.^ the set of possible operator inputs is 
smallj and it is possible to do a much more thorough Job of 
testing than can be done with BOS or service initialization. 
Howeverj hardware problems will happen^ and software bugs will 
sneak through. To cover these cases^ collection 0 includes a 
crash handler that can write a core image to tapej prompting the 
operator for the drive number. 



IblE. IfiEidSLfi 

The toehold, toehold, aim, is an impurej wiredj privileged 
program that resides in a known location in absolute memory 
(24000O). It has entrypoints at the beginning that can be 
entered in one of two ways: with the execute switches processor 
function^ or by being copied into the fault vector. The toehold^ 
thereforej is entered in absolute mode. It must save the 51 2K 
memory image off to diskj and then load in the crash handler. 

The memory image includes the complete machine state. All 
absolute addresses, channel programs^ port and channel number Sj 
and other configuration dependent information is stored into the 
toehold by a PL/ I program^ ini t_ toehold. pi 1 . Thus the aim code 
does not have to know how to do any of these things, which 
simplifies it considerably. 

The toehold starts with the various entry sequencesj one 
for manual entry^ one for Multics entry (which differs from 
manual entry in that the means of entry is to execute the entry 
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through a fault vector entry; it is necessary to update the 
machine conditions in this case to pass the instruction that 
caused the fault vector execution) and one for restarting the 
machine image. The crash entries save the entire machine state. 
This is done under the protection of the memory_ state so that the 
machine state is not overwritten if the toehold is invoked again 
after being invoked after a crash. An internal routine performs 
i/o given a set of dew lists (built by i nit_ toehold) , After the 
memory is saved and the crash handler read inj the machine state 
of bee is restored. ( It was saved by save_handler_mc. ) This 
causes a return into save_handler_mcj which quickly returns to 
ini t_toeho idj which quicKly returns to real_ i n i t i al izer who 
quickly starts the appropriate crash initialization pass. 

On the restore side^ the system is masked and the internal 
routine called to read back the saved image. The machine 
conditions are restored from the toehold (which is not 
saved/ restored during the memory shuffle). 



M9PMLE PE$QRIPTIgN$ 



f imialm 

fim is listed in the crashing set of modules in as much as 
that it contains the bee breakpoint handler. A bee breakpoint 
consists of a "drl -1" instruction. fim's drl handler special 
cases these (in ring 0) j saves the machine state in 
breakpoint_page (after advancing the ic to pass the drl instruc- 
tion) and calls pmut$bee_and„return. It also performs the 
restart from a breakpoint. 



init toehold. Dll 

This pll program constructs the channel programs to save 
and restore the 51 2K memory image^ and fills it and other data 
into the text of toehold. After saving the bee image (crash 
handler) on diskj it calls save_ handler. me to save the current 
machine state of bee in the toehold. When bee is invoked upon a 
crashj the bee restore operation will return to the return in 
save_handler_mc which will return to this point in init„ toehold. 
init„ toehold notices this and quickly returns to real_initial izer 
who will perform the desired crash initialization pass. 



The save_handler_mc programj called from init_ toehold right 
after it saves the crash handler to diskj saves in the toehold 
the machine conditions appropriate for bee. Besides register 



5-2 



AN70-01 



contents and such, it saves the return address to the return 
save_ hand I er _ mc . 
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SECTION 6 



COLLECTION 2 



The main tasR 
accessible. Along 
storage system and 
tions 1 and 2 into 
segment control and 
is also started, 
it does not have 



of collection 2 is to make the storage system 
its way, it loads collection 3 into the 
places the appropriate entities from collec- 
the hierarchy. The sub- tasks are to enable 
directory control. The real traffic control 
Since collection 2 runs in a paged environmentj 
the memory restrictions that collection 1 had. 



This is the 
collection 1. 



reason why it is in 



different collection from 



Ot^OER QE. EXEQgTION 

The operations performed in collection 2 are described 

below. 

ini t ial ize_faults$fault„ init_two is called to change the 
fault vectors into the desired values for normal service opera- 
tion, now that the code for such has been loaded. 

Initialization now runs performing several intermingled 
functions. All hardcore segments must be created now, before 
traffic control is fully initialized. This is so that the 
address space inherited by the new processes (idle in particular) 
encompasses all of hardcore. 

tty_bufj tty_area and tty_tables are generated through a 
call to fnp_init. They won't be needed at this time but must be 
allocated before tc_ i n i t$part_2. 

Unique id (uid) generation is initialized by a call to 
getuidSinit. This is required before segments in the hierarchy 
(in particular, >sl1 and >pdd) can be created. 

init_vtoc_man allocates and initializes the 

vtoc_buf f er_seg. We are therefore eligible to read and write 
(and create) vtoces. 
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dbin_seg is allocated and initialized to an area by 
dbm_ man$ i n i t . init_scavenger_data allocates the scavenger_data 
segmentj used by the volume scavenger. The page control data 
basej dm_journal_seg_j used to control synchronous page opera- 
tions (data management) J is initialized by ini t_dm_ journal_seg. 
di r_ lock_segj used to keep track, of directory lockings and 
waitings thereupon j is initialized by di r_ locK_ i n i t . Againj 
these are created before tc_ init$part_2 is run. 

After this pointj changes to the hardcore descriptor 
segment may not be reflected in idle process and hproc descriptor 
segments. This is because 1 n i t_sys_ var j which sets various 
system variableSj uses the number of supervisor segments present 
(which is the expected total set thereof) to set the stack base 
segment number in various variables and in the dbr. 



We can now run tc_ ini t$part_2, which creates the idle 
processes and starts multiprogramming. At this timej only the 
boot load cpu will be running but the idle process will be enabled 
to run on it. 

With multiprogramming activej syserr_ log_ init can create 
the syserr hproc (after it makes the syserr partition accessi- 
ble). We then log a message to the effect that this was done. 

The activation of segment controlj which began with the 
creation of the sst, continues now with the creation of the 
system trailer seg (str_seg) by ini t_str_seg. If the astk ( ast 
track) parm was specif iedj i n i t_ sst_ name. seg initializes the 
sst_names_ segment with the names of paged hardcore segments. 

The entrybounds of hardcore gates are set via a call to 
init_hardcore_gateSj which also stores linkage pointers into the 
gates for a reason described under the description of the 
program. 

We can finally make the volumes of the rlv accessible for 
storage system activity by a call to accept_rpv. This sets up 
the volume and vtoc maps and stocks for the drives^ allowing 
vtoc_man and the page creation/ destruction functions to work 
against the paging region of the disks. 

The logical volume table ( Ivt) is initialized to describe 
the rlv by init_lvt. 

bad_dir_ and seg_f aul t_handlers are now set up as we are 
about to access our first directory. ini t_root_dir makes the 
root directory known in the Initializer's procesSj creating it if 
this is a cold boot. The functions performed here are those that 
will allow future hierarchy segment references through segment 
control (kst creation^ in particular). fcst_ut i 1$ garbage. col I ect 
is called just to make the kst neat. At this timej we can 
consider segment control to be active. We can call upon it to 
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createj delete or whatever. The presence of the root will allow 
these activities by virtue of the special casing performed by 
segment control when it discovers a segment with no parent (the 
root) . 

The hardcore entities which need to be placed into the 
hierarchy (deciduous segments) are done so by ini t^branchesj 
which also creates >sl1 and >pdd appropriately. These entities 
will be needed when we try to leave ring zero. Of coursej other 
required segments are needed] these are the contents of collec- 
tion 3, 

ini t_stack._0 then runs to create the various stack_0's to 
be shared between eligible processes^ now that it has a place to 
put them. 

delete_segs$temp can now run^ deleting collection 2 tempo- 
rary segments. This ends collection 2. 



M6DULE DESCRIPTIQNS 



accept fs disk. p 11 

A disk, is accepted into the file system by accept_f s_disk. 
It validates the pvte for the disk. The label is read. (If this 
is a pre-MRIO packj salvage_pv is called to convert the vtoc 
region for stock operations.) The pvid and Ivid of this disk are 
copied into the pvtj finally making this data valid. The volmap 
and vtoc map are initialized and the stocks made active by 
i n i t_ volmap_seg. If this failSj the volume salvager is called 
and we try again. The partition map from the label is checked 
against the volmap to make sure that no partition claims pages in 
the paging region. The updated disk label is written out as we 
ex it. _ 



ggpept rpv.pll 

The volumes of the rlv are accepted for storage system use 
by accept_rpv. Firstj the various disks that have hardcore 
partitions are validatedj from their labels^ to be part of the 
rlv. We then scan the intk card to see if the rpv or rlv desire 
salvaging; these facts are stored in the pvt. If the rpv needs 
salvaging^ this is done now ( sal vager$volume_sal vage) , For 
information purposes, we log (or print, if the hcpt parm was 
specified) J the amount of the hardcore partition used on the 
various disks. accept_f s_di sk is called to accept the rpv in the 
normal way. wired_shutdown is enabled as the storage system is 
considered to be enabled. Appropriately, make_sdw$ resets hep is 
called to prevent further attempts to allocate from the hardcore 
partition. Contrary to the name ( accept _ rpv) , the entire rlv is 
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accepted next by calling the salvager^ if necessaryj and 
accept. f s_di sk. for the other rlv volumes. We can then clear 
sal v_data$rpv to Iceep the salvager from salvaging the rpv later. 



create root dir. oil 

During a cold bootj the root is initialized by 
creatc_root_di r . It locks the rootj setting its uid to all ones. 
The various dir header variables are setj pvid, master_dir flagj 
etc. A directory style area is set up along with a directory 
hash table. The dir is then unlocked and we exit. 



create_root_vtbce creates a vtoce for the root directory 
during a cold boot. The vtoce created describes the root as a 
master directory of appropriate lengthy maximum quota limitj 
created as of the current timej primary name of ">", etc. 
vtoc_man is used to allocate space in the vtoc map for this and 
to write it out. 



dbm man.pn 

dbm_man manages the dbm_seg (dumper bit map) for the volume 
dumper. The init entrypoint used during initialization allocates 
and initializes the dbm_seg. Its size is determined from the 
number of disk drives configured and allocated out of the 
hardcore partition by make_sdw. This routine changes dbm_seg 
from its MST status (an abs_seg) to being a real segment. 



The segment used to keep track of directory lockings and 
waitings thereupon^ dir. lock^segj is allocated and initialized by 
dir_ lock_ inid. The size of this segment is based upon 
max_max_el i gi ble (the maximum number of readers of a lock) and 
sys_ i nfo$max_tr ee_ depth (maximum lock depth one can hold). The 
dir_lock_seg is converted from an abs_seg to a real seg^ paged 
out of the hardcore partition. Initial I y^ ten dir_ lock's are 
allocated^ threaded appropriately. 



fnp init,pn 

fnp.init initializes the data bases used in Mul tics- fnp 
communication. tty.buf is allocated in wired memory either with 
a default size or a size specified by the ttyb parm. Various 
header variables are set up. If a tty trace table is called for 
by a conf ig parm, it is allocated in the tty.buf free_ space area. 
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tty^area is initialized as an efnpty area. tty_ tables also has 
its header filled in and its table^area set to an empty area. 
The config file is scanned for fnp cards; each one sets the 
fnp_confiQL flags appropriate to it. The hardware fixed 
dn355_mai Ibox for each fnp is zeroed. fnp_info is set. Final lyj 
i o_ managers ass i gn is called to assign each fnp with an interrupt 
handler of dn355$ i nterrupt . 



qe-^Mid-a\m 

gstuid is the generator of uid's (unique identifiers) for 
storage system objects. Jt operates by effectively incrementing 
tc.dataSid under its own form of lock. The init entrypoint used 
during initialization stores an initial uid "seed" in tc.dataSid 
generated from the clock ..value. 



jinU branphes.pll 

The program that places the appropriate hardcore segments 
into the hierarchyj creating >sll and >pdd as it goesj is 
init_ branches. To start with a clean slate^ it renames the old 
>process_di r_di r and >pdd to a screech name. append then creates 
a new >process_di r_di r (added name of >pdd) which is then 
initiated. The per_process sw is set on for this dir. It is 
given the maximum quota possible. The old >system_l ibrary_1 
Osll) is also renamed and a new one created and initiated. 
Access is set to s for *.«.* on it. We then walk down the 
various sst pools looking for segments to have branches created. 
The sst entry leads us to the sit entry for the segment to be 
placed in the hierarchy. create_branch is called (running 
recursively) to create a branch for the segment (it creates all 
necessary containing directories and a vtoce for the segment). A 
pointer to the parent directory and its aste is found. The aste 
for the hardcore segment is threaded into the parent entry. The 
per_process sWj max_ length and uid fields are set in the aste. 
It is then threaded out of the hardcore lists and into the 
appropriate segment list. The vtoc index provided for the 
segment (found in its entry in the parent directory) is copied 
into the aste so vtoc_man will work. The entrybound of the 
segment is placed into the directory entry. If aste tracking is 
going onj a sstnt entry is added. Its vtoce is updatedj putting 
the correct information from the initialization created aste into 
the vtoce. The parent directory is then unlocked and terminated. 

The per-process sw is turned on in the aste for >pdd so 
that it can propogate down to sons activated off it. We walk 
down >pdd to propogate this switch. The maximum length of the 
sit and name^table are explicitly setj not trusting the site 
fields for them. A maximum quota is reset on >pdd. The default 
acl term of sma * . SysDaemon is removed from >pdd and the acl term 
of sma Ini tial i zer. SysDaemon. z is added. > dumps is created and 
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salvaged if needed. The hierarchy is now properly created and 
active. 



init dm Journal sea. Pi 1 

ini t_dm_journal_seg initializes the page control data base 
dm_ journal_seg_ used to control synchronous page operations. 
This routine parses the dbmj card. This card describes the sizes 
of the various journals needed. Qnce the size of dm_ journal _segL 
is foundj its memory (wired) is obtained from make.sdw. Various 
header pa.'^ameters (pool thresho I ds^ pages heldj events) are 
filled in. The various journal entries have their time stamp 
initialized to tc_data$end_of „t i me. The various page_ entry's are 
threaded into a list. After thiSj sst$ dm_ enab I ed is set for the 
world to knovf, 



init hardcore gates. oil 

i n i t_hardcore_gates performs a variety of functions to make 
those things which are hardcore gates into future usable 
entities. It recognizes anything in the sit with ring brackets 
of Oj Oj n as a hardcore gate. It finds within the text (given 
the definitions) the segdef .my^lp and stores there (having 
forced write access) the linkage pointer for the gate. This is 
done becausej the gatSj known in outer rings by a segment number 
different from the hardcore number j would not be able to find its 
linkage by indexing into the lot by its segment number as normal 
outer ring programs do. Given the segdef . tv_end found for the 
gatej the entrybound is set in the gate's sdw. Final lyj the ring 
brackets for restart_f aul t and return_ to_r i ng_0_ are set from 
their sit values so that these segments may be used in outer 
rings with their hardcore segment numbers. ( return_to_r i ng_0_ 
has a pointer to it stored as the return pointer in the stack 

frame by signaller. return. to_rlng_0_ finds restart_f ault 

through a text imbeded pointer. ) 



The logical volume table is initialized by init_lvt. It 
sets up the header and then uses logical_volume_manager$add to 
add the entry for the rlv. 



inix processor -glm 

A processor is inited by init_ processor. The init 
entrypoint stores the absolute address of various variables into 
in it_ processor itself for execution within absolute mode when 
started on other cpus. When run to start a cpu, it performs some 
collection of tests,, enters appending mode^ fiddles with associa- 
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tive memories and cache^ informs pxss that it is running (through 
its apte) J initializes pds and prds time values^ sends out a 
connect to preempt the processor and then opens the mask to allow 
interrupts. (We will be interrupted at this time (by the connect 
we sent). This will cause us to find our way back, to pxss to 
schedule something to run on this processor.) The idle loop for 
a processor is contained within init_ processor following this. 
The idle loop flashes a moving pattern in the aq lights when it 
is on the processor. At this timej x4 contains the number of 
eligible processes, x5 the term processid and x6 the number of 
ready processes for the sake of checking system operation. 



init root dir.Dll 

The root directory is made known by init_root_dir . We 
start by checking to see if this is a cold boot. If so, 
create_root_ vtoce is called. The root vtoce is read. An aste is 
obtained for the root dir (64 pages) ^ which is initialized from 
the data In this vtoce. pc is used to fill the page table. 
search_ast hashes in this aste. We can now begin the process 
that will allow future segment accessing activity through segment 
control. The Initializer's kst is built, by initial ize_kst. The 
pathname "associative memory" used to map segment numbers to 
pathnames is initialized by pathname_am® ini t ial ize. makeknown_ 
is called to make the root (uid of all ones) known (found in the 
kst). If this is a cold boot, this segment just made known must 
be initialized to a directory by create_root_di r . Finally, this 
directory is salvaged, if necessary. 



init scavenger data.pl 1 

The segment scavenger., data is initialized by 
i n i t„ sea venger _ data . 



init sst name sea .oil 

The sst_names_ segment is initialized by ini t_sst_name_seg 
whenever the astk parm appears. It walks down the sit, looking 
for segments that are paged with page tables in the sst. For 
each, it copies the primary name into the sst_names_ segment. 



init stack O.pll 

The various ring zero stacks (stack_0) are created by 
i n i t_stack_0. Since a process cannot lose eligibility while in 
ring 0, the number of processes that can have frames down on ring 
zero stacks is equal to the maximum possible number of eligible 
processes ( max_max_el igi ble) . We thus create this many ring 0 
stacks which are used by eligible processes. The various 
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stack_0.nnn segments are created in >sn. They are^ in turn^ 
initiated^ truncated^ and prewithdrawn to be 16k. lonQ- The vtoce 
is updated accordingly. The stack header from the initializer's 
ring zero stack is copied into the header of these stacks. The 
stack is then terminated. The acl for Initializer is removed. 
The first stack slot is claimed for the Initializer; the current 
stack being put into the slot in stack_0_data. 



!nit_str_seg initializes the system trailer segment 
(str_seg) into a list of free trailer entries. 



inU gy^ variP\.1 

Now that all of the hardcore segments have either been read 
in or created^ we can now stand back and observe hardcore. The 
next supervisor segment number (mod 8) becomes the ring 0 stack 
segment number (stack base) which is stored in 
act i ve_al l_r i ngs_dats$stack_base^ segno and hcscnt. We make sure 
that the dsegs for the idle processes will be big enough to 
describe these segments. The stack base is stored in the dbr 
value in the apte. Various other system variables are set: 
sys_ inf o$time_of_bootloadj sstSpvhtp (physical volume hold table 
pointer) J sstSrqover (record quota overflow error code^ which is 
moved to this wired place from the paged error_table_ ) j and 
sst$checksum_f i lemap (depending on the nock parm) . 



init volwap sea. p 11 

init_volmap_seg initializes a vol map and vtoc map segment 
allowing us to reference such things on a given physical volume. 
It starts by acquiring an aste for the volmap_seg (for the 
segment abs_seg) and one for the vtoc header (for the segment 
volmap_abs_seg) (vtoc map) which are then mapped onto the desired 
areas of the disk. (This is done under the ast lockj of course.) 
The free count of records is redetermined from the volmap. The 
same is done for the vtoc map. If this is a member of the rlv 
and volume inconsistencies were previously found and the number 
of free vtoces or records is below a certain thresholdj a volume 
salvage is called for. If we will not salvage^ we can accept the 
disk. Use of the hardcore partition on the disk is terminated 
through a call to init_hc_part$terminate_hc_part. Vtoc and 
record stocks are allocated. The pointers in the pvte to these 
stocks are set as are various other status and count fields. The 
number of free records and the base address of the first record 
in each stock page is computed. The dumper bit map from the disk 
is allocated into the dbm_seg (previously created by 
dbm_man$ ini t_map) . Final lyj under the ast lockj we clean up the 
abs_seg and vo I map_ abs_ seg segments (free their sdws) . 
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ini^ vxoc man. oil 



The vtoc_buf f er_seg is initialized by ini t_vl;oc_man. This 
routine acquires enough contiguous memory for the 
vtoc_buf f er_segj determining the number of vtoc buffers either 
from the conf ig vtb parm or from a default. Various vtoc buffer 
headers are initialized here. 



initialize faults. oil 

initial iza_ faults was described earlierj under collection 
1. The entry point f ault_ ini t_two, used by collection 2^ sets up 
fault vectors for normal (file system) operations. It prevents 
timer run-out faults during operation through a call to pmutSldt. 
initial i2;e_faults_data is used to set the main faults. Faults 
set are: command, trouble, segment and linkage to 
f i m$pr i mary_f aul t_entry ( scu data to pdsSf i m_data) , store, mme, 
ftlj lockup, ipr, overflow, divide, dfS, mme2, mmeS, mme4 and ft3 
to f im$signal_entry (scu data to pds$signal_data) , and fault 
numbers 26 to 30 to wired_f im$unexp_f ault (scu data to 
prds$sys_trouble_data) . Access violations are routed specially 
to f i m$ access_ viol at ion_ entry which maps the acv fault into our 
sub-faults. Timer runouts are sent to wired_f im$timer_runout 
(who normally calls pxss> with the scu data stored in 
prd^f im_data. Parity goes to f im$ par ity_ entry. Finally, we set 
up the static handlers for the no_wr i te_permi ssi on, isot_fault 
and lot_fault conditions. 



kst_util performs utility functions with regard to 
maintaining the kst. The garbage collect entrypoint cleans up 
the kst by terminating any segment not known in any ring or a 
directory with no actiye inferiors. 



start CDu.plI 

start. cpu might best be described as a reconfiguration 
program. It is used during initialization to start a idle 
process on each configured cpu (at the appropriate tifne) . When 
starting the boot load cpu in collection 2, it fills in the apte 
entry for the idle process for the cpu in question. Some more 
variables in init_ processor are set ( control I er.data) . A simple 
call out to ini t_processor$start_bootload_cpu can be made. 



syserr log init.pll 

The syserr logging mechanism is made operative by 
syserr. log_ ini t . It creates the segment syserr_log which it maps 
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onto the log partitioHj wherever it is. A consistency check is 
made of the partition; if the check failSj the partition is 
re-inited. The syserr hproc ( SyserrLogger . Daemon. z) ' s ring 0 
stack ( syserr_daemon_ stack) is initialized. The hproc is created 
by create_hprQc$ear ly_hproc with a stack of syserr_ daemon. stack, 
dseg of syserr_daemon_dsegj pds of syserr_daemon_pdSj and proce- 
dure of syserr_ logger . A fast channel is defined for communica- 
tion through syserr_data to the hproc. Logging is now enabled. 



tc„ i n i t was descr i bed ear I i er to set up and i n i t i a 1 i se 
tc_data. tc_ ini t$part_2j in collection Z, starts up 
multiprogramming by creating the idle processes. This entry can 
only be called opce the Initialzer's dseg is completely filled in 
by all those who read or create hardcore segments. Various 
variables in template_pds are filled in which are applicable to 
the idle processes. For each configured processor, a copy of 
temp I at e_ pds and the initializer's dseg is made into appropriate 
entries in idle_dsegs and idle_pdses. The stack_0 for these 
processes is made to be the ppds for the given processor. The 
initial process for the bootload processor (the initializer 
himself) is created by threading in an apte specifying 
i n i t_ processor as an initial procedure. It is placed in work 
class zero. tern is initialized to indicate only this one process 
running. Various polling times are set for when polling becomes 
enabled as we start multiprogramming. in i t_ processors i n i t sets 
up the rest of the state. We can now call start_cpu to start the 
bootload cpu idle process. 
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SECTION 7 



COLLECTION 3 



The main task of cpllec%ion ^h^ee is to read itself into 
the hierarchy. Collection three consists of those programs that 
are necessary to reach ring one in the initializer's process and 
to be able to perform a reload function (and other maintenance 
functions). A few extraneous functions are also performed in 
collection three. 



QBDEB. SL EXECMTION 

Collection three starts with its main function: 
load_system is called to read the remaining mst entities into the 
hierarchy. At this time^ the mst reading function is shut down. 

i o_conf i Q_ i n i t initializes the data in i o_conf i g^data for 
use in later econf igurat ion activities. ioi.init is called to 
prepare for outer ring usage of physical devices. 

tc_ init$ start. other_cpus starts up the other processors. 
We now consider collection three done and set 
sys_ i nf o$ i n i t i a I i zat i on„ state to .4 . 

real_ initial izer finally finisheSj returning to 
initializer. initializer can then delete in it segs through 
delete_segs$ initj real_ initial izer being part of one. 
Initialization then finishes by a call to init„proCj to call out 
to ring one command level. 



init_proc is the first program run in ring zero in a normal 
process. It calls out to the initial procedure for a process in 
the outer ring. For the Initial izerj the initial_proc is made to 
be system_startup_ . The setting of the working dir is skipped^ 
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since we can't be sure it's there yet. The ring one stack is 
created explicitlyj by makestack. system. startup, is initiated, 
cal l_outer_r i ng_ is called to "return" out to ring one (outward 
calls are not allowed) to transfer to system. startup. . 



io confia init.pll 

i o_conf i g_data is initialized by io_conf ig_ init. (It was 
allocated memory and its base pointers set up by get. io.segs. ) 
The tables are initialized in the order: iom and mpc^ channel 
and then devices (as it indeed must be). 

Filling in the iom and controller entries is easy; they are 
one for one with iom and mpc cards. 

A walk is made of prph cards twice. The first pass is made 
to f i 1 1 in the channel entries. Each prph card is found. If the 
peripheral is a disk or tape (has an mpc) j we also find a chnl 
card (if present). Each channel is added to the channel list. 
The internal routine control ler. i dx.from.chan i d looks up the 
index into the controller array for the controller owning this 
channel (via ioi.conf ig$f ind. control ler.card) , The internal rou- 
tine i om_ i dx_ from. Chan i d finds the corresponding iom array entry. 
After all of thiSj each channel is linked to its base physical 
channel via calls to ioi.conf i g$f ind. base. channel . 

A second pass over prph cards is made to fill in the device 
entries. For each devicej we start by finding its physical 
channels. (This is done by walking down all the channels (from 
the prph and chnl cards) j looking up the base channel (from the 
channel entries) and making an array of the physical channels 
found ( tempi ate.pchan. array ) , If any of these channels is 
configured (it was marked configured above because its iom was 
on)j the device becomes configured on. The device entry is 
filled in from the card. For disks and tapesj though^ we add a 
device entry for the controller and one each for each drive. 



ioi init.pll 

ioi.init sets up the various ioi. data bases. It walks the 
config deck^ allocating group table entries for each channel 
group. Each device whose channel is accessed through a control- 
ler has its group entry flagged as a psia. The device table 
entries and channel table entries are allocated from information 
on the prph card. Then, for each chnl card, the group table 
entry corresponding is found and the channel table entries 
allocated from the information on the chnl card. The base 
logical channel for each group is found. The group entries are 
then traversed to find storage system disk channels. All 
non- storage system disk channels are assigned to ioi. through 
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io_manager. As a final gesiure^ the ioi_ page tables are setup 
( ioi_page_ tables init) . 



io! page table. oil 

The init entrypoint of ioi_page_ table is called during 
initialization to set up the io_ page. tables segment. It starts 
by abs wiring the segment as one page (initially) and zeroing it. 
The header Is initialized. Sixty-four word page tables are 
allocated and initialized within this pagej as many as will fit. 



tOPd ^y^tefTirPU 

Collection three is loaded into the hierarchy by 
load_ system. It reads the mst source ( disk_reader ) looking for 
segments. For eachj i n i t_branches$branch is called to create the 
branch ( init_ branches is described under collection two). The 
appropriate acl is set up, given the mst information. The 
segment contents are copied into the created branch. If the 
Initializer does not have write access to the final segment j the 
acl is cleared of this acl entry. 



tc inlt.pll 

tc_init was described earlier. The entrypoint 

start„other_cpuSj starts cpus other than the boot load cpu at the 
end of collection three (after their interference won't matter). 
A prds for the various non-bootload processors is created and 
entry- he Id. The pds and dseg for the other cpu's idle processes 
was already created so we can now call start_cpu on this new cpu 
as we would normally during reconfiguration. 
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SECTION 8 



MEQHAN I SMS 



This chapter describes certain tricky and not so tricky 
mechanisms used within initialization to get things done, Also 
included is a look at the mechanism by which the various parts of 
the supervisor come into operation. 



HARDC6RE SE6MENT CREATIQN 

There are various ways that segments come into being within 
the hardcore. These mechanisms are usually quite distinct from 
the normal method of creating a segment within the hierarchy 
( appends foo) . 

The first group of segments that are created are those 
needed by collection zero. Collection zero itself is read in in 
absolute mode; no segments exist other than those hardware 
supplied. To save collection zero the problem of generating 
segments for its use in absolute node^ its segments are generated 
by macros within template_sl t_ . aim. These macros generate not 
only the sit entries for collection zero segments (and various 
segments at fixed absolute memory addresses^; they also generate 
the page tables and the segment descriptor words for the 
segments. A much simpler program in absolute mode ijioves these 
page tables and sdws (the dseg) to appropriate places and loads 
the dbr (also generated by template_slt_) . ThuSj these early 
segments come quickly and magically into being. All of the 
segments described by the template_sl t_ are data segments with no 
initial content except for bound_bootload_0 itself , which was 
loaded into the correct memory address by the boot load tape 
label J and toehold, by virtue of being the first part of 
bound_ boot I oad_ 0 , 

The second group of segments to come into being are the 
collection one segments loaded by collection zero. These seg- 
ments are created through a mechanism imbeded in boot I oad_ loader 
and boot load. dseg. When the segment header (actually a sit 
entry) is read from the MSTj the need for a segment of a certain 
size is called for. Values in the sit header keep track of the 
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extent of memory allocated. The type of segment (permanent 
"unpaged" or not) determines from what end of memory the space 
will be obtained. A page table of appropriate size is 
constructed in the proper area (either the segment 
unpaged_page_ tables for permanent "unpaged" segments or 
int_unpaged_page_ tables for temporary or to be made paged seg- 
ments), A new sdw pointing to this page table is tacked onto the 
appropriate end of dseg (low segment numbers for permanent 
segmentSj high for temporary or init segs) . With write access 
set on in this sdWj the segment contents can be loaded from tape 
into the memory area. Proper access is then set in the sdw. The 
segment is now existent. 

Collection one creates certain data segments that are wired 
and contiguous, The most obvious is the sst. These are created 
by the routine get_main. get_main might toe considered the 
counterpart of the collection zero segment creation mechanism 
when called in collection one. It also allocates memory space 
from values in the sit header. A page table of appropriate 
length in one of the two unpaged page table segments is 
constructed and a sdw fabricated to this page table. The caller 
of get_main forces this sdw into dseg and performs the appropri- 
ate associative memory clearing function. 

The other type of segment created by collection one is a 
paged segment. There are two cases of this. The first is a 
paged segment that is to be mapped against a previously defined 
area of disk. This is done when we want to access a partition or 
part thereof J as when we want to read the conf ig deck from disk. 
To do this, make. sdw is calledj specifying that we want an sdw 
for an abs-seg. make„sdw finds us an aste of appropriate size 
and threads it into the hardcore lists^ but senses the abs-seg 
switch and does not allocate pages or whatever. The caller of 
make^sdw builds its own page table within the aste obtained by 
calling ptw^ut i l_$make_di sk to make each page table word point to 
the correct disk record. The pvtx of the desired disk is 
inserted into the aste. ThuSj references to this segment (whose 
sdw points to the page table in this aste) will wake up page 
control who will page in the proper pages. This mechanism 
appears in several placesj the desired way of generating such a 
segment is to call map„onto_di sk. 

The second type of paged segment created by collection one 
(or two for that matter) is a segment paged off the hardcore 
partition. In this casej allocation of pages is done by page 
control. make_sdw is called as before^ but, this time, it not 
only creates an aste for the segment, but it finds space for it. 
A disk with a hardcore partition with enough free space to hold 
the segment is selected. This pvtx is put into the aste. As an 
added bonus, since such segments will not have trailer entries, 
the trailer pointer in the aste is set to the hardcore segment 
number (for those programs that need to map the hardcore aste 
list entries to sit entries). The page table words are set to a 
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nulled state. make^sdw then touches each pagej causing page 
control J when the page fault occur Sj to withdraw a page from the 
partition. ( init_hc_part created a vol map and record stock that 
page control can use which describes only the hardcore parti- 
tion.) With the segment now in existence^ the caller of make.sdw 
can now load the segment. For collection one or twoj this 
involves either initializing the data segment or copying in the 
segment contents read from the mst. 

When collection two needs a wired contiguous data spacej it 
calls get_main also. In this casej though^ get_main calls 
make_sdw$ unthreaded which will obtain an aste and sdw and page 
space. pc_abs$wire_abs_cont i g is then called to wire this 
segment into contiguous memory pages. A paged segment to be 
mapped onto a particular area of disk, is created as described for 
collection one. . 

Hardcore segments that need to be placed into the hierarchy 
(deciduous segments) are so placed as follows. append is called 
to create a branch, This creates a vtoce for the segment and 
makes activej creating if necessary j all parent directories. 
Normal lyj segment control activities would then create an aste 
for this being created segment which would be threaded as a son 
of the parent directory's aste. In this initialization case^ 
thoughj the aste for the new segment already exists. We hand 
thread this aste into the normal segment lists and thread it as a 
son of the parent directory's aste. The directory entry for this 
segment created by append gives the vtoc index of the vtoce for 
it. By placing this vtocx into the old aste for the new segment, 
vtoc_man can make the vtoce for this now deciduous segment 
reflect the placement of this segment in the hardcore partition 
(where it was allocated during hardcore initialization). The 
segment is now properly active and accessible from the hierarchy. 



The initialization of the hardware and configuration infor- 
mation pertaining to it (basically scs (and also iom.data)) is a 
little understood process. To better understand the method of 
initialization, it is necessary to start with an understanding of 
the operation of the hardware on which Multics runs. This 
description pertains to the DPS- 8 hardware series. The descrip- 
tion for the Level -68 series is similar but is not included. 



I ntprponnect i on s£. Mmlt ic^ hatrdw^re 

A Multics system consists of a set of system control units 
(SCU's)j central processing units (CPU's) and input/ output 
multiplexors (lOM's). 
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A SCU controls access to memory. Each SCU owns a certain 
range of (absolute) memory. Any active unit (a CPU or an lOM) 
that requires access to memory does so by requesting the access 
from the SCU that owns the given range of memory. 

A CPU performs the actual computations within the system. 
It operates by requesting instructions and data from the appro- 
priate SCUSj operating upon them^ and placing the results into 
appropriate locations in SCUs. 

An lOM performs input and output to physical devices. It 
requests data from SCUs to send to devices and taices data from 
devices^ storing it into SCUs. 

lOMs and CPUs are not directly connected to one another. 
The only method of commun i cat i on between active modules is 
through a SCU. The connection of modules in a Multics system is 
therefore something like the following. 



I I0M A I I I0M B I 



1 \/ I 
I /\ I 



I MEM A I - - - 1 SCU A I I SCU B 1 1 MEM B I 



I CPU A I J CPU B I 



The crosses indicate that both lOMs and both CPUs connect 
to both SCUs; the CPUs and lOMs are not themselves connected. 

The active modules (CPUs and lOMs) have up to four ports 
that go to SCUs. These are referred to as the memory ports of 
the active module in question. The SCUs have up to eight ports 
that can go to active modules. These are referred to as the 
active module ports of the SCU or just simply as SCU ports. 

All CPUs and lOMs must share the same layout of port 
assignments to SCUs. ThuSj if memory port B of CPU C goes to SCU 
Dj the memory port B of all other CPUs and lOMs must go to SCU D. 
All CPUs and lOMs must describe this SCU the same; all must agree 
in memory sizes. Also^ all SCUs must agree on port assignments 
of CPUs and IQMs. Thus, if port 3 of SCU C goes to CPU Aj then 
port 3 of all other SCUs must also go to CPU A. 
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Conf i aura-t i on fi£ flM UigS hgr^W^r^ 

The various hardware modules need varying amounts of 
configuration description information with which to run. 



CPU AND ion HARDWARE CQNF I GURAT I ON 



The CPUs and lOMs require access to main memory. They 
resolve their own internal concept of memory address (virtual or 
io page table) into an absolute main memory address. This 
address must describe a location in one and only one memory store 
unitj which itself must be connected to only one SCU. The lOM or 
CPU must determine which SCU owns the memory location desired^ 
and supply that SCU with the address relative to its base of the 
location desired. The CPU and IQM do this with the memory 
configuration information known to them by configuration switches 
and changed under software control. 

The configuration data known to the processor (at the 
hardware level) is found via the rsw instruction with operands of 
1 and 2j which can be obtained by calling pmutSrsw with these 
operands. The format of the data returned is described in 
rsw. incl.pll and also shown below. 

The data returned by the rsw 2 instruction is shown below. 



bits meaning 



0 


1-3 


4-word/2- word interlace C if enabled) 


4 


-5 


processor type (01 for DPS-8) 


6- 


12 


seven msb's of the fault base 


13- 


13 


id prom installed 


19- 


19 


dps (marketing) option 


20- 


20 


8k cache option 


23- 


23 


Multics model CPU 


24- 


24 


Multics mode enabled 


29- 


32 


CPU speed (0 = 8/70, 4 = 8/52) 


33- 


35 


cpu number 



The data returned by rsw 1 consists of four nine bit bytes 
describing each of the four possible memory (SCU) ports of the 
processor. The bytes appear in order in the result^ SCU 0 in the 
high order bits. The format of the byte is: 



b i ts mean i ng 



0-2 port assignment 

3- 3 port is enabled 

4- 4 system initialize is enabled 

5- 5 port is interlaced with neighbor 

6- 8 memory size 
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The actual memory size of the memory attached to the SCU attached 
to the processor port in question is 32K « 2 *« (encoded memory 
size). The port assignment couples with the memory size to 
determine the base address of the SCU connected to the specified 
CPU port (absolute address of the first location in the memory 
attached to that SCU). The base address of the SCU is the 
(actual memory size) « (port assignment). 

The lOM has similar port description information 
interpreted similarly. This information is not readable from the 
CPU, 



SCU HARDWARE CONFIGURATION 

The SCU also has description of its ports (to CPUs and 
lOMs) as well as description of the store units attached to it. 
This information is determined by the rscr instruction 
(pmut$rscr)j given the SC_CFG argument. (The explanation of the 
rscr instruction appears later.) The portions of the result that 
pertain to SCU port and store unit configuration are shown below. 



bits 



mean i ng 



09-1 1 
12-15 

21- 21 

22- 22 

23- 29 
30-30 
31 -31 
32-35 
57-63 
68-71 



lower store size 

store unit ( A A1 B B1 ) on-line 

SCU in program mode ( vs manual) 



non-existant address 
non- existent address 
st or e unit i nter I ace 
B is lower addressed 
port enable mask for 
cyclic priority (0/1-6/7) 
port enable mask for ports 4 



checking enabled 
limit 
enabled 
store ( vs A) 
ports 0-3 



A DPS- 8 SCU may have up to four store units attached to it. 
If this is the casej two store units form a pair of units. The 
size of a pair of units (or a single unit) is 32K « 2 ** (lower 
store size) above. 

If the non-existant address flag is on^ any address to a 
store unit whose high order bits (above the lower 15) is greater 
than or equal to the non-existant address limit generates a 
non-existant address SCU illegal action. 

A SCU will respond to and provide information to only those 
ports that are enabled (port enable mask above). 

SCU ADDRESSING 



There are three ways in which an SCU is addressed. In the 
normal mode of operation (memory reading and writing)^ an active 
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unii ( IGM or CPU) translates an absolute address into a memory 
port (on it) and a relative memory address within the memory 
described by the memory port. The active module sends the 
address to the SCU on the proper memory port. If the active 
module is enabled by the port enable mask in the referenced SCUj 
the SCU will take the address given to it and provide the 
necessary memory access. 

The other two ways pertain to reading/ setting control 
registers in the SCU itself. For each of these^ it is still 
necessary to specify somehow the memory port on the CPU whose SCU 
registers are desired. For the rmcm^ smcm and smic i nstruct i onSj, 
this consists of providing a virtual address to the processor for 
which bits 1 and 2 are the memory port desired. 

The rscr and sscr j nstruct ions^ though, key off the final 
absolute address to determine the SCU (or SCU store unit) 
desired. ThuSj software needs a way to translate a memory port 
number into an absolute address to reach the SCU. This is done 
with the paged segment scaSj generated by init.scas (and 
init_scu). seas has a page corresponding to each SCU and to each 
store unit in each SCU, pmutSrscr and pmutSsscr use the memory 
port number desired to generate a virtual address into seas whose 
absolute address (courtesy of the ptws for seas) just happens to 
describe memory within that SCU. 

The cioc instruction (discussed below) also depends on the 
final absolute address of the target operand to identify the SCU 
to perform the operation. In the case of the cioc i nstruct ion^ 
thoughj this has no particular impact in Multics software. All 
target operands for the cioc instruction when referencing lOMs 
are in the low order SCU. When referencing CPUSj the SCU 
performing the connecting has no real bearing. 



^ ^^^^ co'"""'^ ' e^t i on 

As mentioned earlierj communication between active modules 
(CPUs and lOMs) can only be performed through SCUs. 

CPUs communicate to lOMs and other CPUs via the cioc 
connect i/o channel) instruction. The operand of the instruction 
is a word in memory. The SCU containing this operand is the SCU 
that performs the connect function. The word fetched from memory 
contains in its low order bits the identity of a port on the SCU 
to which this connect is to be sent. This only succeeds if the 
target port is enabled (port enable mask) on the SCU, When the 
target of the connect is an lOMj this generates a connect strobe 
to the lOM, The IQM examines its mailbox in memory to determine 
its course of action. When the target of the connect is another 
CPUj this generates a connect fault in the target processor. The 
target processor determines what course to follow on the basis of 
information in memory analyzed by software. When a connect is 
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sent to a processor (including the processor issuing the con- 
nect), the connect is deferred until the processor stops 
executing inhibited code (instructions with the inhibit bit set). 

Signals sent from an lOM to a CPU are much more involved. 
The basic flow is as follows. The lOM determines an interrupt 
number. (The interrupt number is a five bit value, from 0 to 31. 
The high order two bits are the interrupt level. 

0 - system fault 

1 - terminate 

2 " marker 

3 - special 

The low order three bits determines the lOM and lOM channel 
group, ) . •• ■ 

0 - lOM 0 channels 32-63 

1 - lOM 1 channels 32-63 

2 - lOM 2 channels 32-63 

3 - ISM 3 channels 32-63 

4 - lOM 0 channels 0-31 

5 - lOM 1 channels 0-31 

6 - lOM 2 channels 0-31 

7 - lOM 3 channels 0-31 

It also takes the channel number in the group (0-31 meaning 
either channels 0-31 or 32-63) and sets the <channel number>th 
bit in the < interrupt number >th memory location in the interrupt 
mask word ( IMW) array in memory, It then generates a word with 
the < interrupt number>th bit set and sends this to the boot load 
SOU with the SXC (set execute cells) SOU command. This sets the 
execute interrupt cell register in the SCU and sends an XI P 
(execute interrupt present) signal to various processors 
connected to the SCU. (The detai Is of this are covered in the 
next section.) One of the processors (the first to get to it) 
sends an XEC (execute interrupt cells) SCU command to the SCU who 
generated the XI P signal. The SCU provides the interrupt number 
to the processor, who uses it to determine the address of a fault 
pair in memory for the "fault" caused by this interrupt. The 
processing of the XEC command acts upon the highest priority 
(lowest numbered) bit in the execute interrupt cell register, and 
also resets this bit in the register. 



I n^grrup-fr Masks aOfil Assignment 

The mechanism for determining which processors are candi- 
dates for receiving an interrupt from an lOM is an involved 
topic. First of all, a processor will not be interrupted as long 
as it is executing inhibited instructions (instructions with the 
inhibit bit set). Beyond this, though, lies the question of 
interrupt masks and mask assignment. 
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Internal •to the SCU are two sets of registers (A and B) j 
each set consisting of the execute interrupt mask register and 
the interrupt mask assignment register. Each execute interrupt 
mask, register is 32 bits long^ with each bit enabling the 
corresponding bit in the execute interrupt cell register. Each 
interrupt mask assignment register has two partSj an assigned bit 
and a set of ports to which it is assigned (8 bits). When a bit 
is set in the execute interrupt cells register^ the SCU ands this 
bit with the corresponding bit in each of the execute interrupt 
mask registers. If the corresponding bit of execute Interrupt 
mask register Aj for examplej is onj the SCU then looks at the A 
interrupt mask assignment register. If this register is not 
assigned ( enabled) ^ no further action takes place in regards to 
the A registers. (The B registers are still considered (in 
parallel , by the way).) If the register is assigned (enabled)j 

then interrupts will be sent to all ports (processors) whose 

corresponding bit is set in the interrupt mask assignment 
register. ThuSj only certain interrupts are allowed to be 
signalled at any given time (based on the contents of the execute 
interrupt mask registers) and only certain processors will 
receive these interrupts (as controlled by the interrupt mask 
assignment registers). 

In MulticSj only one processor is listed in each of the two 
interrupt mask assignment registers^ and no processor appears in 
both. ThuSj there is a one for one correspondence between 
interrupt masks that are assigned ( interrupt mask registers whose 
assigned (enabled) bit is on) and processors who have an 
interrupt mask (SCU port number appears in an interrupt mask 
assignment register). SOj at any one time only two processors 
are eligible to receive interrupts. Other processors need not 
worry about masking interrupts. 

The contents of the interrupt mask registers may be 
obtained with the SCU configuration information with the rscr 
i nstruct i on and set w_i th the sscr i nstruct i on. 

b i ts mean i ng 

00-07 ports assigned to mask A ( interrupt mask assignment A) 

08-08 mask A is unassigned (disabled) 

36-43 ports assigned to mask B ( interrupt mask assignment B) 

44-44 mask B is unassigned (disabled) 

The contents of a execute interrupt mask register are 
obtained with the rmcm or the rscr instruction and set with the 
smcm or the sscr instruction. The rmcm and smcm instruction only 
work if the processor making the request has a mask register 
assigned to it. If notj rmcm returns zero (no interrupts are 
enabled to it) and a smcm is ignored (actually, the port mask 
setting is till done). The rscr and sscr instructions allow the 
exami n i ng/sett i ng of the execute interrupt mask register for any 
port on a SCU; these have the same effect as smcm and rmcm if the 
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SCU porx being referenced does not have a mask assigned to it. 
The format of the data returned by these instructions is as 
f ol lows. 



bits meaning 

00-15 execute interrupt mask register 00-15 

32-35 SCU port mask 0-3 

36-51 execute interrupt mask register 16-31 

68-71 SCU port mask 4-7 



Qaerat i ons upQn ma£]S& 

Since at most two processors have interrupt masks assigned 
to themj not all processors can manipulate their own masks. Butj 
to remove the need for processors to ask whether they have a mask 
before operating upon them (in partiuclarj to mask interrupts) j a 
mechanism has been devised. It's execution is carried out by by 
pmut$set_mask and pmutS read. mask. The code fragment of pmut that 
reads/ sets the mask follows. 



read. mask: 



Ixll prdsS processor. tag 

I pr pab scs$ mask_ p t r j x 1 
xec scs$read.maskj x1 



set. mask : 



1x11 prds$ processor. tag 

I pr pap scs$ mask^ ptr j x 1 
xec scsSset.maskj x1 



For each processor tag^ thenj there is a set of data pointers and 
instructions in scsSmask.ptr j scs$read_mask and scsSset.mask that 
either operate upon the processor's mask or pretend they did. 
When the processor in question does not have an interrupt maskj 
the data is as follows: 

mask. ptr - packed pointer to 
pr ds$ s i mu I at ed. mask 



read. mask: 

I daq ab 1 0 

set. mask : 

staq ab I O 



which will succeed in doing nothing. When the processor does 
have an interrupt mask^ the data is as follows: 

mask. ptr - packed pointer to 

scs$ por t. address inoLwordCbootload scu ) 
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read_mask: 

rmcm ablOj« 



set_mask: 

smcm abfOjiK 

which will read and set the mask. The array 

scsS port_addr ess i ng_ word contains the data words required as 
operands for the rmcm, smcm and smic instructions. They contain 
the memory port number in their low order bits ( i . e. j their array 
index is their contents). The smic instruction uses 
scs$ i nterrupt_ control ler (the low order memory port (address 0) ) 
as ian array index to perforn) the smic against the low order SCU. 

The operands of the pmut$read_mask and pmut$set_mask opera- 
tions (rmcm and sm.cm instructions, respectively) were described 
above. The value scsSsys. level masks all interrupts. It has 
zeroes for all bits loaded into the execute interrupt mask 
register but has all ones for all ports of the SCU to which 
enabled active modules are connected. scs$open_ level has the 
same SCU port enable bits but has ones for all interrupts of all 
levels from both channel sets of all lOMs currently active. 



Configuration initialization occurs primarily within 
scs_and_clock_ ini t, iom_data_ ini t, scas_init and init_sGu called 
from within scas_init. 

The name of this routine should probably be just scs_init. 
The clock portion is really just a check of clock functioning 
(and setting up clock data in general). It fills in the 
scs$port_addressi ng_ word' s as described above. 

scs$processor_swi tch_data is read to get the configuration and 
data switch values. scs$bos_processor_tag is set to indicate 
this cpu (currently the only one running) as the boot load cpu. 
scs$read_maskj scs$set_mask and scs$mask_ptr are set to the dummy 
values mentioned above. When scs_and_clock_ init is run, all 
interrupts are masked, and no one really needs to think about its 
masks. The various processor ports are examined looking for 
memories. The port number of the low order memory so far is set 
into scsS interrupt_control ler and sys_ inf o$clock_ . When 
scs_and_clock_ init is finsihed, then, the configuration data for 
the boot load cpu is known, as well as for the various memories 
attached to it. Examination of this data and setting of masks 
waits for later programs. 

i om_data^ i n i t initializes the data needed by io_ manager. 
This includes descriptions of the various lOMs and their chan- 
nels. The basic setup of this information (numbers of IQMs, 
numbers of channels) was set up by get_io_segs who obtained this 
data from the config_deck. Most description of lOMs appears in 
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iom_data so no major changes take place to scs within 
i om_clata_ i n i t. 

Aside from filling in scw's and Ipw's for each 
channel_table and mailbox entryj the more interesting part of 
iom_data_ init is the main lOM card processing loop. It examines 
each I0M cardj making sure that no I0M is duplicatedj that the 
field values are reasonable^ that no card claims an SCU port 
claimed by another I0M (and sets scs$port_data to claim the lOM) 
etc. The iom_data. per. iom data is initialized as to configured, 
on_linej pagedj etc. This routine adds to scsS open. I eve I the 
necessary bits to enable interrupts from the lOMs, C Interrupts 
are not enabled until initial ize.faulstS interrupt. init. ) 

The conclusion of configuration initialization occurs in 
scas^init and its servantj init.scu. At its entry, scsSport.data 
has been set up to only describe the lOMs. This routine will set 
these for processors. It also initializes seas, as its name 
implies. This requires determining all memories and store units. 
Aside from this, the routine checks the port enable switches for 
the processor ports for correctness. 

The first loop of interest scans all CPU cards. It checks 
them for reasonableness, that no CPU is mentioned twice, that no 
other active module claims this SCU port, etc. The cow's 
(connect operand words) used when perforoing cioc's to this 
processor are set. 

What follows this is the SCU scanning loop. It takes each 
MEM card and checks it for reasonableness, whether tags are 
duplicated, whether the memory extent (from rsw.util) matches and 
does not overlap any other memory, etc, init_scu is then called. 

init. SCU initializes an SCU. This is the routine that sets 
up seas for a particular SCU. This is done by installing ptw's 
into the page table for seas to describe the SCU. Reading the 
configuration from the SCU, the data is compared against the 
computed data given the processor configuration information 
(which seas. in it compared against the config_deck description of 
the memory). If the configuration from the SCU indicates 
aditional store units, the seas pages for them are set (to allow 
getting the store unit mode registers with an rscr). 

The mask checking part of init.scu makes sure that each 
interrupt mask that is assigned on the SCU is assigned to a 
processor (as opposed to an lOM) and that no more than one mask 
indicates a given processor. This is done by walking down the 
CPU data in scs and comparing the mask data recorded for the 
other processor ports for duplication. This also records which 
masks assigned for this SCU are claimed by processors. Any mask 
that is assigned that does not appear in the description of a 
processor is mi s-assi gned. 
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After the SCUs have been initialized in this way^ a little 
more work is left. The bootload CPU's ports are checkedj so that 
no extra port is enabled. For each IQM (and the bootload CPU), 
the port enable bit is set in each SCU. 

For each processor j we find the processors with masKs 
assigned. For these, we set scs$set_inask.j scs$read_mask and 
scsSmask^ptr to actually perform the rmcm and smcm instructions 
as described above to manipulate their masks. We check to be 
sure that the bootload CPU owns one of the masks. 

The final loop examines the ordering of active modules on 
the SCUs to see if the cyclic priority switches can be set. This 
is only done if the lOM group does not overlap the CPU group. 



P A iS E cg NT RQL INITIALIZATION 

Page control initialization consists of a variety of 
activities run during collection one. init_sst build the sst and 
core_map. The sst is needed since we need to have an aste for 
page control so that it can find what disk needs i/o (from the 
pvtx within the aste). The core^map is needed since it shows the 
status of memory pages (initially free between the groups of 
initialization segments, currently wired). Page control needs 
this information so it can find a free memory frame into which it 
can read a desired page. init_pvt performs the function of 
creating the pvt. It is the index into the pvt for the device 
from which a page (or other i/o) is desired that is needed by 
disk_control (dctl). read_di sk$ i n i t is needed to initialize page 
reading/wr it ing through rdisk_seg. This routine builds the paged 
segment rdisk.seg, which can be mapped onto the desired page of 
disk to read. The aste for rdisk_seg contains the pvtx of the 
disk to read. The page table word for rdisk_seg provides the 
disk address. At this point, we can actually read or write a 
page by touching rdisk_seg within read_disk. read_disk sets up 
the aste and page table word, as described. When the page is 
touched, a page fault will wake up page control. It will find a 
free memory frame, read the page in, and resolve the page fault. 

read_di sk_ label uses read_disk, then, to read a disk label, 
ini t_root_vols uses read_di sk_ label to read the label of hardcore 
partition volumes. Given the label, it finds the partition map 
and finds the hardcore partition. A small vol map is built that 
describes this partition and is mapped onto the beginning of the 
partition. A small record stock is built to describe the vol map. 
Given this initial stock, attempts to create or free pages on a 
disk (within the hardcore partition) can succeed. Now, we can 
create hardcore segments by building null page tables and taking 
page faults. Page control will find a free page from the vol map 
for the partition (whose pvtx is in the aste) and resolve our 
page fault. At this point, all of the services we need of page 
control are available. For the ease of later activities who need 
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various partitions to map paged areas ontOj i n i t_part i t i ons is 
called to validate the part information. We now page happily. 

Later J in collection twoj the real vol maps and record 
stocks are set up by accept_rpv. After this pointj page control 
will simply shift its page creati on/ freeing activity to that 
described by the paging region. All hardcore segments had their 
pages pre- withdrawn from the hardcore parti t ion j so no possibili- 
ty exists that we will accidentally put a paging region page into 
a hardcore segment. 



SE;gm^NT Bm PIREgTgRY CONTRQL ^NlTiALIZATIQN 

Segment and directory control are initialized in stages 
throughout collections on© and two. It started in collection one 
when the sst was built. It continues into collection two with 
getuidSinit. This allows us to generate unique ids for newly 
created segments and directories. i n i t_ vtoc_ man paves the way 
for vtoc_man to perform i/o on vtoces. Segment control's trailer 
segment is created by i n i t_str_seg. accept_rpv sets up the real 
vtoc maps and vtoc stocKs. Now vtoc.man can really read and 
write vtoceSj as well as create and free them. NoWj if we were 
to try a normal activation of a segmentj given its pvtx/vtocx, we 
could find the segment and thread the segment into the right 
astes and trailers. init_lvt builds an initial rlv (in the Ivt) 
out of the disks listed as having hardcore partitions. This 
allows segment control's disk selection algorithm to be able to 
find a disk to use when segments try to be created. We now have 
enough mechanism in place to utilize most of the facilities of 
segment control^ but we cannot yet access and activate hierarchy 
segments. 

The initialization of directory control is imbedded within 
the initialization of segment control. It started with 
dir_ lock_ init providing us with an initially empty list of locked 
directories. The real start up of directory control, though, 
occurs in ini t_root_dir . This builds the kst (used at segment 
fault time to resolve segment numbers into an understanding of 
what needs activation) and creates ( if need be) and activates and 
initiates by hand the root directory. Directory control can now 
reference hierarchy objects with segment control's help. Any 
attempt to create a hierarchy segment (append) can succeed by 
selecting a disk (Ivt lookup), vtoce creation (vtoc_man using 
vtoc stock, vtoc map and vtoc buffers) and aste creation (using 
sst and the trailer seg) . Also, deactivation is possible since 
the trailer is built to describe what to setfault and the kst is 
present to be able to re-activate. At this point, we are able to 
handle segment faults, given the information in the kst and by 
recursively traveling down the hierarchy by virtue of the fact 
that the root Is now and always active. 
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SEGMENT NUMBER ASgifi NflENT 



There are basically three classes of segments as far as 
segment number assignment is concerned. The first is segments 
that will be a permanent part of the supervisor. These are 
assigned consecutive segment number Sj starting at 0. dseg is 
always Oj of course. 

The second class is initialization and collection temporary 
segments. These are assigned consecutive numbers starting at 400 
octal. Although temporary segments are deleted at the end of 
each collectionj their numbers are not re-used. We continue to 
assign the next non-used number to the next temporary or 
initialization segment. 

The order of assignment of these numbers is purely 
according to the order that the segments are encountered. The 
first few segments are assigned numbers by template_sl t_ j butj 
againj this is in order of encounter ance. The only requirements 
are that dseg must be segment 0 and that the sit must be segment 
7 (assumed by all dump analyzers). 

Normal hierarchy segments fall into the third class of 
segments^ as far as segment number assignment is concerned. As 
for thesBj the sequence is as follows. The next higher mod 8 
segment number after the last permanent supervisor segment is 
chosen as the stack base (ring zero stack number). The next 
seven numbers are assigned to the outer ring stackSj in order. 
Since the root is made active after thiSj and the root becomes 
the first real hierarchy segment initiatedj it gets the segment 
number after stack_7. Other segments are assigned progressively 
higher segment numbers according to segment control's normal 
rules. We do not need to worry about running into segment number 
400 octal since these segments will be deleted before we ever get 
that far, Only permanent supervisor segments will show up in 
one's dseg_. _ _ 

Some supervisor segments (deciduous segments) get initiated 
into the normal user's address space. Regular stacks are 
initiated by special handling (makestack called from the segfault 
handler) and are directly referred to by the reserved stack 
segment numbers. A normal segment like bound_ I ibrary_l_ is 
activated through normal segment control means. Thus, it will 
appear in two places in the user's address space; one in the 
supervisor segment number range (with ring brackets of Oj 0, Oj 
by the way) and once in the user ring segment number range 
(greater than the root's segment number) (with ring brackets of 
Oj nj n) . 

This is a problem for hardcore gates^ though, relative to 
their linkages. A user ring call to bound_ I i brary_ 1 _ will cause 
modules within it to find their linkage section from the lot 
entry for this segment. Any module called from bound_ I !brary_1_ 
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will also be in the user ringj so the user ring linkage section 
for the segment number corresponding to the user ring version of 
bouncl_l ibrary_l_ will find the called module. Hardcore gates, 
however J don't call hierarchy entities but instead call entities 
that can only be found through the linkage section generated via 
pre- linking during initialization which resides in the ring zero 
linkage section corresponding to the hardcore segment number. To 
make it possible to find this easilyj ini t_hardcore_gates stored 
into the hardcore gate segdef .my_lp the pointer to this linkage 
section. Thus, when called from the outer ring with the outer 
ring segment number^ hardcore gates will quickly switch over to 
the hardcore linkage section and function properly. 



TRAFFIC cgNTROL INIHALI ZATIQN 

All three collections contribute efforts toward enabling 
traffic control. Collection one starts by building the tc_data 
segment in tc_initj full of empty aptes to describe processes. 
At this time, though, a flag in tc_data indicates that 
mult- programming is not active. Any call to traffic control to 
pxssSwait will simply loop for notification (which will come from 
a call to pxssSnotify in some interrupt routine). No polling 
routines are run at this time. Other initialization activities 
proceed to build the supervisor address space, 

Collection two starts up multi -programming. It does this 
through tc_ init!£part_2. Multi -programming requires 

mul t i -processes; initially this is the Initializer and an idle 
process, but it soon encompasses answering service created 
processes and hardcore processes (hprocs). Creating an idle 
process requires creating a pds, stack_0 (prds) and dseg for it. 
The dseg and pds are simply copies of those for the Initializer, 
now that they are filled in. apte entries for the Initializer 
and for idle are created. We can now consider multi -programming 
to be on. start_cpu is called to start the processor. For the 
boot load processor, this means calling ini t^processor in a 
special case environment (non-absolute mode, if nothing else), 
i n i t_ processor (the idle loop) marks itself as a running 
processor, sends itself a connect, and unmasks the processor. 
The connect will go to traffic control, who will pre-empt idle 
and return control to Initializer. 

In collection three, start_cpu is called (from 
tc_ i n i t$start_other_cpus) in the same manner as would be done for 
adding a cpu during reconfiguration. This is somewhat described 
in the reconfiguration manual. 
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SECTION 9 



SHUTDOWN AND EMERGENCY SHUTDOWN 



The goal of shutdownj ofeviously enough, is to provide an 
orderly cessation to service. A normal shutdown is one in which 
the system shuts itself dowHj following the direction of the 
operator's "shut" command. An emergency shutdown is that opera- 
tion invoked by bee which forces Multics to run 
emergency.. shutdown, which performs the clean up operations below, 

One could consider the system to be shutdown if one simply 
forced a return to bee, but this is not enough. Proper shutdown 
involves, at first, the answering service function of logging out 
all users. The answering service then shuts itself down, 
updating final accounting figures. Now with just the Initializer 
running, the task of shutdown described here follows. 

The major goal of shutdown and cmergency_shutdown is to 
maintain consistency of the storage system. It is necessary to 
move all updated pages of segments to disk, to update all 
directories in question with new status information, to update 
vtoces of segments referenced, and to clear up any effects caused 
by the creation of supervisor segments. 

These functions must be performed in several stages. Also, 
the ordering of operations is such as to minimize the degree of 
inconsistency within the storage system that would occur if a 
failure were to occur at any point. 

Since these same functions are performed for an emergency 
shutdown, the operations are performed so as to assume as little 
as possible from the Information in memory. 



ORDER QE. EXECUTIQN fiE SHUTDOWN 

The module shutdown is called via hphcs_$ shutdown. It 
starts by removing the fact that we were called from an outer 
ring, so we won't accidentally return. An any_other handler is 
set up to flag any possible error, later. The first action of 
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shutdown is to force itself to run on the boot load cpu and to 
stop the others (stop_cpu). 

disk_emergency$test_al l_dr i ves checks out all of the stor- 
age system drives at once to avoid errors later. 

tc_ shutdown destroys the remnants of any processes and 
turns off mult i -processing. 

scavengers shutdown cleans up any scavenges that were in 
progress. 

We then switch over to the stack. inzr.stkO for the rest of 
shutdown, This is performed through the aim routine^ 
switch_shutdown.fi I e_systemj which starts the file system shut 
down. 

shut down_f i I e_ system is the first program called on 
inzr_stkO. It is a driver for the shutdown of the file system. 
It starts by updating the rpv volmap^ vtoc header (and vtoc map) 
and label of the rpv to show the current state ( in case problems 
occur later) . 

The most important step^ from the user's point of vieWj is 
to flush all pages in memory (considered to be part one of 
shutdown) with pcSflush. This is relatively easy and safe to 
perform since it only requires walking down core map entriesj sst 
threads^ etc. do not have to be trusted. This marks the 
completion of (emergency) shutdown^ part 1. 

The stack zero segments are released so that demount.pv can 
deactivate them. 

deact i vate. for. demounts shutdown deactivates all 

non- hardcore segments and reverts deciduous segments (removes 
from the hierarchy those supervisor segments put into the 
hierarchy during initialization). This updates the directories 
containing those segments that were active at shutdown time (and 
thei r vtoces) . 

Our next task is to remove the pages of these updated 
directories from memory. We start by demounting all operative 
disks (other than the rpv) with demount_pv. After thiSj if any 
locks remain set^ we set the shutdown state to three] it is 
normally four. 

If any disks are inoperativej we just perform another 

memory flush (to remove rpv directory pages) j wait for console 
i/o to finish ( ocdcm_$drain_ io) and return to bee. 

If all was okayj we demount the rpv with demount_pv. The 
storage system is now considered to be shut down. The ssenb flag 
in the flagbox is reset to show this. We flush memory once more. 
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to QOt, the last log messages out. The message "shutdown 
complete" is printed; we wait for console completion, Shutdown 
can now return to bee. 



SBDE& 2E EXECUTIQN QE E nERQENPY SHUTPOHN 

emergency^ shutdown is called from bee. bee modified the 
machine conditions of the time of return to bee to cause a return 
to emer gency_ shutdown I 0. This module initializes itself through 
text imbeded pointers to its linkage sectionj etc. and enters 
appending mode. 

Multi -programming is forced off ( te_data$wai t_ enable) . 

The aptj, metering and various . apte locks are forced 
unlocked. 

The return to bee earlier stopped all of the other cpus. 
scsSprocessor is set to show this fact. 

The connect lock is forced unlocked. 

Various trouble pending^ etc. flags are reset in case of 
another f ai lure. 

scs maskSj etc. are set up for single (boot load) cpu 
operation. We mask down to sys_level. 

A switch is made to the idle process. This is done by 
using scs$ idle_aptep to find the idle's apte. Its dbr is loaded. 

All other cpus are set to delete themselves^ in case they 
try to start. 

The idle process has prds as its stack. A stack frame is 
pushed onto this stack by hand. 

The ast and reconfiguration locks are forcibly unlocked. 

The first external module is called. ocdem_$esd_ reset 
resets oc_dataj and the console software. 

syserr_real$syserr_ reset resets the syserr logger and the 
syserr_data segment and flags, 

io_ managers reset resets iom^data status. 

pages esd_ reset resets its view of the disk dim. 

pc_reeover_sst recomputes the page control state. 
pageSt ime.out is called. 
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disk_emergency$test_al l_dri ves_maskecl runs as for normal 
shuidownj but in a masked state. 

The prds is abandoned as a stack (it is reset) and the 
stack pointer set to null (idle process), The first page of 
tempi ate_pds is wired and the sdw for pds set to point to 
template_pds (hopefully a good pds). The first page is touched, 
hopefully successfully paging in the page. The stack pointers 
are then set to inzr_stkO, We then call 

w i red_shutdown$w i red_ emergency. 

wired_shutdown sets an any_ other handler and unmasks the 
processor. It makes a few checks to see if the storage system 
was enabled. If a vtoc_buffer is in the unsafe statej its 
physical volume has its trouble count incremented. 

For each pvte, the scavenger data is reset as in a normal 
shutdown. page$ reset. pvte is called. Emergency shutdown part 1 
is started. 

fsout_vol updates the rpv information on disk as for 
shutdown. 

Pages of segments are flushed from information in the core 
map entries (pcSflush). The rpv information is again written. 
This ends part one of emergency shutdown, 

vtoc_man$stabl i I ize gets vtoc buffers into shape. 

We can now call shutdown_f i le_ system and let normal opera- 
tions carefully try to update directories and vtocesj as for a 
normal shutdown. 



<;jQgigt \ y^%^ fqr tjlepiQMnt ■ P 1 1 

Other than the flushing of pages themselves, the 
deactivation of segments (updating their directory entries and 
vtoces) performed by deact i vate_f or_demount is one of the most 
important functions of shutdown. The deactivations are performed 
by hand so as not to disturb aste threads. The operation 
consists of walking down the ast hierarchy (tree)-wisej 
recognizing that each . active segment has all of Its parent 
directories also active. We start at the root. For each segment 
to consider, we look down its inferior list. Each look at an 
aste and an inferior element is performed with a variety of 
validity checks on the aste (within pool boundaries, parent/son 
pointers correct, etc). , If inferiors exists, they are pushed 
onto a stack (max hierarchy depth deep) of astes to consider. 
When we push an aste with no Inferiors, we consider it directly. 



9-4 



AN70-01 



If it was a hardcore segment ( deci duous) j it is removed from the 
aste list it is in and its vtoce freed. Non-hardcore segments 
have their pages flushed (pcScleanup) if they are not entry- held 
(entry- he Id segments^ such as pdses had their pages flushed 
earlier and will be caught in the final flush) and their vtoces 
updated ( update_vtoce!$deact) . After a segment is consideredj its 
brothers are considered. When they are donej we return back to 
their parent for consideration. We proceed in this manner until 
we consider and pop the root aste off the stacic. Segment control 
is now no longer active. 



demoMni;^ pv,pl1 

demount_pv demounts a physical volume. It starts by 
waiting for everyone to relinquish the drive; that isj no one can 
be in the middle of a physical volume operation. All segments on 
the volume are deactivated. For the shutdown case described 
herej a special deactivation is performed to avoid possible 
problems in the case of emergency shutdown. Each aste pool is 
traversed (by numerical order, not link order because of possible 
mis- I inkings) . All non- hardcore segments (except the root) are 
deactivated in-line by calling pcScleanup and update. vtoceSdeact 
on the segment. We then wait for all vtoc i/o to complete to the 
disk. fsout_vol is called to update the volmapj vtoc header and 
map and the label. Finishing, we clean up the pvt entry. 



<;;lisK emergency -pU 

To ease the burden on shutdown of drives being inoperative, 
disk_emergency$test_al l_dr i ves is called. It tests all storage 
system drives by first assuming that each one is good, then 
running di sk_ controls test_dr i ve. If the drive is declared inop- 
erative this time, it is marked as such with an error report 
printed. Shutdown of objects on this drive will be suspended. 



emergency shMt;dQwn.q\m 

bee, when crashed to, received the machine conditions at 
the time of the call to bee, For an emergency shutdown (esd), 
bee patches these to force a transfer to emergency_shutdown 1 0. 
Mult i -programming is forced off ( tc_data$wai t_ enable) . The apt, 
metering and various apte locks are forced unlocked. The return 
to bee earlier stopped all of the other cpus. sc^processor is 
set to show this fact. The connect lock is forced unlocked. 
Various trouble pending, etc. flags are reset in case of another 
failure. ses masks, etc. are set up for single (bootload) cpu 
operation. We mask down to sys_ level. A switch is made to the 
idle process. All other cpus are set to delete themselves, in 
case they try to start. The idle process has prds as its stack. 
A stack frame is pushed onto this stack. The ast and 
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reconfiguration locks are forcibly unlocked, ocdcni_$escl_ reset 
resets oc_dataj and the console software. 

syserr_real$syserr_reset resets the syserr logger and the 
syserr_data segment and flags. io_ manager* reset resets iom_data 
status. pages esd_ reset resets its view of the disk dim. 
pc_recover_sst recomputes the page control state. pageSt i me_out 
is called. di sk_emergency$test_al l_dr i ves_masked runs as for 
normal shutdown^ but in a masked state. The prds is abandoned as 
a stack (it is reset) and the stack pointer set to null (idle 
process). The first page of template_pds is wired and the sdw 
for pds set to point to template.pds (hopefully a good pds) . The 
first page is touchedj hopefully successfully paging in the page. 
The stack pointers are then set to inzr_stkO. We then call 
w i r ed_ shut do wn$ w i r ed_ emergency . 



fsQut vol .Pll 

fsout_vol is called whenever a volume is demounted, This 
includes the shutdown equivalent function. It endeavors to 
update the volume mapj vtoc header and map and label for a 
physical volume. It drains the vtoce stock for the disk 
( vtoc_stock_manSdrain_ stock) to return those vtoces withdrawn 
previously. The vtoc map is then forced out to disk. We can 
then free the vtoc stock. We similarly drainj write out and free 
the record stock/ map. The dumper bit map is freed and updated to 
disk. The time map updated and mounted is updated in the label. 
If this is the root^ this is the program that records in the 
label such useful information as the di sK. table. vtocx and uid and 
the shutdown and esd state. 



The shutdown entrypoint to scavenger is called during 
shutdown to clean up any scavenge operations in progress. It 
walks down scavenger _ data looking for live entries. For each* it 
clears the corresponding pvte fields deposi t_to_volmapj 
scav_check_ address and scavenger_.block_rel which affects the 
operation of page control. 



shutdown. Pl1 

This is the starting driver for shutdown operations. It is 
called from hphcs_$shutdown from the Initializer command 
shutdown. It forces itself to run on the bootload cpu and it 
stmps the others. di sk_emergency$test_al l_dr i ves test the drives 
before use, tc_shutdown stops and destroys the other processes, 
scavenges are stopped ( scavenger* shutdown ) , We then switch 
stacks back to inzr_stkO and proceed through shutdown within 
swi tch_shutdown_f i I e_ system. 
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shutdown file sy stem. oil 



shutdown_f i le_system is the driver for the shutdown of the 
file system. It runs on inzr_stk.O. Its operations include." 
fsout_vol updating of the rpvj flushing pages of segments^ 
releasing stack._0 segments for deactivation purposesj running 
deact i vate_f or_demount$shutdown to deactivate non-hardcore seg- 
ments and revert supervisor segments threaded into the hierarchy 
at initialization (updating directories as a result) and then 
flushing memory again (by calls to demount_pv for the various 
disks). This module keeps track of the state of operat i veness of 
dr ivesj if any are inoperativej we just perform a final flush and 
quit] otherwise we cars demount the rpv also. A final flush is 
performed to get syserr log pages out. After console i/o has 
drainedj we can return to bee. 



switch shutdown file system .aim 

swi tch_shutdown_f i I e_. system is the first program in a set 
to shut down the file system. It moves us back to inzr_stkOj the 
initialization stack for our processing. While it is fiddling 
with stack po inter Sj it also sets pds$stack_0_ptr and 
pds$stack_0_sdwp. On this new stackj it calls 

shutdown. fi I e_ system. 



tc shutdown . d I 1 

Traffic control is shutdown by tc_shutdown. It flags the 
system as being in a shutting down state 

( tc_data$system_ shutdown ) . It also sets wait_enable to 0, 
disabling multi-programming. For each process in the aptj 
deact i vate_segs is calledj destroying the process and finishing 
our task. 



V/ired shutdown, oil 

The module wired. shutdown is the counterpart to shutdown in 
the esd case. It starts by setting an any_other handler and 
unmasking the processor. It makes a few checks to see if the 
storage system was enabled. If a vtoc.buffer is in the unsafe 
statej its physical volume has its trouble count incremented. 
For each pvtej the scavenger data is reset as in a normal 
shutdown. page$reset_pvte is called. Emergency shutdown part 1 
is started. fsout_vol updates the rpv information on disk as for 
shutdown. Pages of segments are flushed from information in the 
core map entries (pcSflush). The rpv information is again 
written. This ends part one of emergency shutdown. 
vtoc_man$stabl i I i ze gets vtoc buffers into shape. We can now 
call shutdown_f i le_ system and let normal operations carefully try 
to update directories and vtocesj as for a normal shutdown. 
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APPENDIX A 



GLOSSARY 



abs-seg 

An abs-seg is a reserved segment number in the hardcore 
address space used to access disk or memory outside of the 
normal mechanisms. That is, they are not built by the 
normal functions that append to the storage system nor are 
they built by the functions that create segments out of the 
hardcore partition or initialization memory. Examples of 
abs'segs are segments mapped onto an area of disk to allow 
paging to be used to read/v/rite them (such a mechanism is 
used to read the conf ig deck, from disk) or segments mapped 
onto an area of memory for examination (page control does 
this to examine pages being evicted). abs-segs are managed 
( i . e. J created and deleted) j each in its own way^ by a set 
of software created for the purpose; One may not use the 
standard system functions to operate upon them (such as 
segment deletion). However j the contents of the segments 
are addressed through normal mechanisms; that is, memory 
mapped abs-segs are referencable via the hardware and 
abs-segs built with an aste/page table pair in the sst are 
allowed to have page faults taken against them. 

bee 

The Boot load Command Environment within boot load Multics, 
that iSj the collection of programs and facilities that make 
up a command level that allows certain critical functions to 
be performed before storage system activation occurs during 
system initialization. 

boot load Multics 

Those early parts of initialization that are capable of 
booting bee from a coldj bare machinej including bee itself. 

cold boot 

A boot load in which the state of all hardware and peripher- 
als is unknown. In particular, the Multics file system is 
either non-existant or has been destroyed. This is also 
known as an initial boot. 
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col lect i on 

A "collection" is a set of programs read in as a unit that 
together perform a function during initialization. Collec- 
tions are referred to by number j starting with zero. Each 
CO 1 1 ect i on depends on the mechan i sms initial! zed by the 
collections that preceded it. As each collection finishes 
its task., some of that collection is deleted and some is 
keptj depending on the requirements of future collections. 

There are also fractionally numbered collections, which 
consist of support entities for the preceding collection- 

The division of initialization into collections is done 
based upon var i ous restr i ct i ons i mposed by the course of 
initialization. For example, since the first few collec- 
tions must run entirely within memoryj restrictions on 
available memory (and the amount that can be required of a 
system) force unessential programs into later collections. 

cont i guous 

A contiguous segment is one whose memory locations describe 
contiguous absolute memory locations. Most segments do not 
have this requirement] their pages may appear arbitrarily in 
memory. Certain segmcntSj though, such as the sst_seg must 
have their locations in order, due to hardware requirements 
for placement of their contents. 

coo I boot 

A boot load in which the Multics file system is on disk and 
believed to be good but in which the state of memory and 
other peripherals is unknown. In particular, bootload 
Multics is not running. The mpc's may or may not have 
firmware running in them. The system is loaded from the MST 
(tape) and initiated via iom switches. 

crash 

A failure of Multics. This may be the result of a hardware 
or software failure that causes Multics to abort itself or 
the result of an operator aborting it. A crash of Multics 
during early initialization can produce a tape dump of 
memory. Crashes after this time can be examined with bee 
utilities or saved to disk by bee and analyzed later. 

dec i duous segments 

These are segments generated or read in as part of 
initialization which are given branches in the hierarchy (by 
in it_ branches ) . Although they become part of the hierarchy, 
their pages remain in the hardcore partition and are 
therefore destroyed between bootloads. Examples are the 
segments in >sn and the Initializer's pds. (The name 
suggests the leaves of trees. ) 
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deposi t 

A page control concept, 
of free objects. 



1 1 means to add an obj ect to a I i st 



dseg 



descriptor segment (see data bases) 



dump 



A subset of Multics segments saved after a crash that can be 
examined through various dump analysis tools to determine 
the cause of the preceding crash. A dump is either a disk 
dumpj a dump performed to the dump partition of disk by the 
dump facility of bce^ or an "early dump", one performed to 
tape dur i ng ear I y i n i t i a I i zat i on . 



early initialization 
Those parts of 
Mu 1 1 i cs command 
boot I oad Mu 1 1 i cs 
initial i zat ion. 



initial i zat ion 

level. All 
command level 



needed to reach boot I oad 

activities after leaving 
are referred to as service 



emergency shutdown 

A Multics operation, invoked by bee, that runs a subset of 
the hardcore facilities to shut down the file system (put 
the storage system into a consistent state) after a crash. 



esd 



emergency shutdown 



hardcore 

The supervisor of Multicsj loosely 
collection of programs and segments 
during initialization. 



def i ned. 
generated 



This is a 
or read in 



hproc 



A hardcore process, Such a process is created by a call to 
create_hproCj as opposed to being created through the 
answering service. Such hprocs (currently 

SyserrLogger , Daemon and riCS_T i mer_ Daemon. SysDaemon) perform 
activities integral to the system operation and must be 
created prior to, and independent ofj the answering service. 



init segments 

Segments needed only during the course 
These are deleted after the end of 
col lection. 



of initialization, 
the last hardcore 



initial i zat ion 

The action of starting Multics. 
the appropriate software modules 
and constructing the appropriate 
an event J such as someone trying 



This consists of placing 
in the appropriate places 
software tables such that 
to dial a login line, or a 



page fault occur ing, etc. will invoke the proper software 
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which will be in a position to perform the necessary 
operation. 

k.st 

known segment table (see data bases) 

Ivt 

logical volume table (see data bases) 

MST 

Mult ICS system tape 

Multics system tape 

The "tape" is the set of Multics programs that will make up 
the supervisor in un-pre- I i nked form. This set of programs 
originates on a tapej some of them spend part, of their lives 
in a disk partition. 

nondeci duous 

A hardcore segment not mapped into the hierarchy. These 
segments live in the hardcore partition and are known only 
by having sdw's in the hardcore address space. 

partition 

An area of a storage system diskj other than the labelj 
vtoCj volume map and paging area. These areas can be 
accessed by paging mechanisms but are not used to hold pages 
of storage system segments. Hardcore segments are mapped 
onto the hardcore partition so that they may be usedj and 
early initialization can runj without touching the file 
system proper. 

pre- \ inking 

As the Multics supervisor is read from the MST^ the various 
modules are linked together. This operationj called 
pre-linkingj is similar to linking (binding) that occurs 
during normal service operation for user programs, except 
that it consists of running through all segments and finding 
all external references and resolving them. This is done 
during initialization for efficiency^ as well as for the 
fact that the dynamic linker cannot be used to link itself. 

ptw 

page table word 

ptwam 

page table word associative memory 

pvt 

physical volume table (see data bases) 

root physical volume 

The main disk drive. it can never be deleted. This drive 
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is used to hold the original hardcore partition as well as 
the partitions required by bee and is therefore required at 
an early point in Multics initialization. 



rpv 

root physical volume 

seas 

system controller addressing segment (see data bases) 

scs 

system communications segment (see data bases) 

sdw 

segment descriptor word 

sdwam 

segment descriptor word associative memory 
shutdown 

The orderly cessation of Multics service^ performed such as 
to maintain consistency of the storage system. 

sit 

segment loading table (see data bases) 
supervisor 

A collection of software needed for operation of user's 
software and support software provided for the user. This 
would include software to make disk accessing possible, to 
provide scheduling activity^ etc. The supervisor in Multics 
is referred to as "hardcore". 

temp segments 

Segments needed only during one collection. They are 
deleted at the end of the major collectionj before load^ing 
the next collection. 



uid 



un i que i dent i f i er (of a segment ) 



unpaged 

A segment that is not paged under the auspices of page 
control. Such a segment has its page table either in 
unpaged_page^ tables or int_unpaged_page_ tables. Except for 
the possible presence of the breakpo i nt_pagej these segments 
are contiguous. During early init ial izat ion^ all segments 
are generated to be of this type. The program 
make_segs_ paged forms paged segments that are copies of the 
pagab^le initialization segments. Certain wired segmentSj 
thoughj are left unpaged. 
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In previous releases, unpaged segments were literally 
unpaged, that is, they had no page table and had the unpaged 
flag set in their sdw. Currently only fault_ vector , 
iom_mailboxj dn355_mai Ibox, i sol ts_abs_segj abs_seg and 
abs.segl are of this type but will receive page tables in a 
future release. 



vtoc 

The volume table of contents of a storage system volume. 
The vtoc is divided into entries Cvtoce), each of which 
describes a hierarchy segment contained on that volume. 



warm boot 

A bootload in which the Multics file system is present on 
disk and believed good, and in which bootload Multics is 
running on the processor. This type of bootload of Multics 
is performed from disk. 

wi red 

A page, or set of pages, is wired if it cannot be moved from 
memory by page control, 

withdraw 

A page control concept^ said of records and vtoces, It 
means to remove an object from a list of free objects. 
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APPENDIX B 



INITIALIZATION AND INITIALIZED DATA BASES 



This appendix describes various data bases k.ept by 
initialization or that are generated by initialization. As suchi 
this list incorporates the most significant data bases within the 
system. 



A I LI NKAGE (ACTIVE INII LINK A GE) 

This initialization segment corresponds to area. linker for 
initialization programs that will be paged. This area is built 
by boot I oad_ loader and segment_ I oader from linkage sections found 
on the MST. 



AS UNKAQE (ACTIVE SMPERVISQR L I NKAGE? 

This hardcore segment corresponds to area, linker for paged 
supervisor programs. It is shared across processes^ and can 
therefore contain only per -system static such as initialization 
static variables (when only one process is running) or system 
wide countersj etc. The linkage areas are formed in here, by the 
various MST loading programs. 



BQE DATA (&gQTLQAP C gMMANP E NVlpgNMENT D ATA ? 

bce_data keeps information that pertains to the command 
environment features of boot load Multics. It contains entries 
that describe the main pseudo i/o switches (inputs output and 
error) as well as the state of exec.com and subsystem execution. 



BOQTLQAD INFO 

bootload_ i nf Oj generated initially from bootload_ inf o. cdSj 
contains various information about the state and configuration of 
early initialization. It contains: the location of the bootload 
tape ( iomj controller channel, drive number and drive and 



B-1 



AN70-01 



controller type provided by the lOM boot function)^ status about 
firmware loading into the boot load controller, the location of 
the rpv (iorij controllerj drive number and drive and controller 
type provided in the f i nd_rpv_ subsystem dialog), the location of 
the bootload console (and type) , a variety of pointers to other 
data baseSj as well as the master flags indicating the presence 
of BOS and the need for a cold boot. All of this data is copied 
into sys_boot_ i nf o during generation and during system 
initialization. Most references to this data are therefore to 
sys_boot_ inf o. 

boot load_ info. cds has provisions to contain si te-suppl ied 
configuration information. If these values are provided, no 
operator queries will be needed to bring the system up. Only 
cold site boots or disk problems would require operator interven- 
tion during boot. It is intended that an interface will be 
provided to fill in these values, such that generate^mst could 
set the values into the segment and the checker could report 
their settings in the checker listing. 



CONFIP PEQK 

Historically namedj the config_deck contains the descrip- 
tion of the configuration. It contains one entry (card) for each 
iom, cpu, memory, peripheral subsystem, etc, in the configura- 
tion. It also describes various software parameters. These 
entries are referenced by programs too numerous to count. It is 
built initially by init_ear ly_conf ig to describe enough of the 
system to find the rpv and read in the real conf ig_deck saved in 
a partition thereon. (If this is a cold boot, in which there 
would be no conf ig_ deck, the conf ig_ deck is entered manually or 
from the MST through the config deck editor,) After this time, 
it becomes a wired (at its initialization address) abs-seg mapped 
onto the "conf" partition. Various reconfiguration programs 
modify the entries. 



CORE MAP 

One of the page control data bases, the core_map describes 
frames of memory available for paging. Each entry describes a 
page frame. When a frame is used (it has a ptw describing it), 
the disk address of the page occupying the frame is kept in the 
core^map entry. init_sst initially builds the core_map. It is 
updated to accurately describe the state of pagable memory by 
make_segs_ paged, which frees certain unpaged segments and 
col lect_f ree_core which works to find various holes between 
segments. Page control maintains these entries. 
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PPM C PUMPER Bii ME. SEBl 



dbm_seg holds the dumper bit maps used by the volume 
dumper. It is paged off the hardcore partition. Its 
initialization as an area was performed by dbm_ manS i n i t . Each 
configured disk, drive has two maps here^ one for the incremental 
dumper and one for the consolidated dumper. The segment starts 
with the usual lock, control informationj and meters. After this 
comes an area in which the bit maps are allocated. Each bit map 
consists of a bit corresponding to each vtoce on the volume in 
question. The bits indicate the need to dump the various 
segments. 



DIR LOCK SEG 

d i r_ I ock_ seg keeps track of lockings of directories and on 
processes waiting thereupon. It has a header with a lock and 
various status. Each dir_lock entry contains the uid of that 
which is lockedj various f lagsj threads to a more recently locked 
entryj and the array of process ids for the various lockers (more 
than one only for all readers). 



DISK POST QUEUE SEG 

A part of page_control , disk_post_queue_se0 is an obscure 
data base used to keep track of disk i/o postings that could not 
be made because the page table was locked at the time of i/o 
completion. 



DISK SEG 

The disk seg contains the various tables (except the pvt) 
used by disk_control and dctl to perform i/o to disks. It is 
split into the tables disk_dataj disktabj chantabj devtab as well 
as the queue of disk i/o requests. disk_data contains entries 
giving the names and locations within disk_seg of the disktab 
entry for each configured disk subsystem. The disktab entry 
contains various subsystem meterSj as well as holding the queue 
entries for the subsystem. Also contained herein are the chantab 
and devtab entries for the subsystem. Each chantab entry lists a 
i/o channel to use to perform i/o to the subsystemj given as an 
io_manager index. It also holds various per channel meters, and, 
most importantlyj the dew list that performs i/o on the channel. 
The devtab entries^ one per subsystem drive, describe the drives. 
This consists of status information ( inoperativej etc.) as well 
as per drive statistics. 
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DM JSURNAL SEG 



A page control dara basSj dm_ j ourna\_seg_ is used to keep 
tracK of page synchronization operations for data management. It 
is allocated and initialized by ini t_dm_ journal_seg. It starts 
with a lock, for manipulating the journal entries as well as the 
usual wait event information. Also present are information about 
the number of pages held in memoryj the maximum pages held, the 
number of journalSj etc. Corresponding to each aste pool is a 
structure containing a threshold and number of active, 
synchronized segments. Following this are various meters. Then 
comes the journal entries and then the page entries. Each 
journal entry contains the tim^ stamp that determines when pages 
of the segment being held can be written (when the journal was 
written) J the number of pages heldj and a relative thread to the 
I ist of page entries for the pages being held, A pa^e entry 
contains the threads that make up this list, a relative pointer 
to the core map entry for the page, and a relative pointer to the 
journal entry for the page. 



DN355 DATA 

This data seg, initialized by fnp_initj contains global 
information on each configured fnp. Data for each fnp includes: 
a pointer to the hardware ma i I box ^ pointers to the dew lists and 
the physical channel blocks (pcb)j the number of subchannels, the 
iom/ channel info, indexes into the pcb for I si as and hslas 
(hmlcs)j status of the delay queues, various flags about the 
state of fnp operations, the let (logical channel table) entry 
pointer, status of boot loading, and various counts of free 
blocks, input and output data and control transaction counts, 
etc. 



The dn355_mai Ibox is a set of mailboxes at fixed hardware 
addresses. They start with the fnp pew. Also present are 
various counts of requests and the fnp crash data. Following 
this are 8 Multics initiated sub- ma i 1 boxes and 4 fnp initiated 
sub- ma i I boxes. The sub-mailboxes describe the line for which the 
operation is being performed along with the data for that 
operat i on. 



PSEg IBESSElPiaR SEGMENT! 

The descriptor segment is a hardware known data base. It 
contains a sdw (segment descriptor word) for each segment within 
a process' address space. The ultra important processor register 
dsbr (descriptor segment base register), also called the dbr, 
indicates the absolute address of the page table describing it. 
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The sdw of a segment indicates the address of the page table of 
the segment (which contain the locations of the pages of the 
segment) and other information^ such as the length of the 
segments accesses allowedj etc, dseg must be segment 0, The 
initial dseg is generated by template.sl t_ and copied into dseg 
by boot load_abs_mode. Entries are added by bootload_dsegj 
get_main and make_sdw as segments are loaded from the MST. The 
generation of sdws Is integrated with the creation of sit 
entrieSj and the allocation of memory/disk, that the sdw/ page 
tables effectively describe. 



FAULT VECTQR (FAULT MEL I NTERRUFT VEQTgRg? 

This is another hardware known data base^ at a fixed 
absolute memory address (O). It contains two words for each 
possible fault and interrupt. Normal ly^ each entry contains a 
scu instruct ionj to store all machine conditionSj and a tra 
instruct iorij to transfer to the code that handles the 
fault/ interrupt. These two instructions are force executed in 
absolute mode on the processor. The entries are filled in by 
boot load_f aults and init ial ize.faults. During some phases of 
ini t ial izat ionj when a particular fault/ interrupt is to be 
ignored (such as a timer running out)j the fault vector entry is 
set to a scu/rcu patr^ which stores machine conditions and then 
reloads themj returning to the point of interruption. The scu 
and tra instructions actually perform indirect references through 
"its" pointers that are present following the interrupt vectors 
within this segment. During normal operationSj only these 
pointers are changed. 



The flagbox is s)n area of memoryj at a known addresSj that 
allows communication between Multics operation and boot load 
Multics. This area contains information from Multics to boot load 
Multics such as the fact that we are crash ingj and here's what 
exec_com to run. Boot load Multics can pass information up when 
booting^ such as being in unattended mode so that Multics will 
know how to boot. The area is examined by various programs and 
set through commands/ act i ve functions in both Multics and 
bootioad Multics operation. This area is within the bee toehold. 



This is the stack used by initialization and shutdown. The 
name stands for initializer stack. Originally wiredj it becomes 
paged during initialization. Once the actual ring 0 stacks are 
created and after collection 3, initialization will leave this 
stack (in init_proc). Shutdown will return to this stack for 
protection as the stack_0's are deleted. 
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INT UNPAGED PAGE TABLES 



The page tables for init and temp segments are kept here. 
It gets an initial value through template^sl t_ and is managed by 
the various segment creation routines. Once make. segs_ paged is 
run J no unpaged segments exists whose page tables are hepe. SOj 
we delete this segment. The page table for this segment is 
contained within it. 



IQ CQNFIG DATA 

The inter -relationship between perlpheralSj mpc's and iom's 
is described in i o_conf i g_data. It cpntains a set of arr ays^ one 
each for deviceSj channels^ controllers and ioms. Each entry^ 
besides giving the name of each instance of said obJectSj gives 
indexes into the other tables showing the relationship between it 
and the rest. (That is^ for examplej each device shows the 
physical channels going to it; each channel shows the mpc for itj 
etc. ) 



IQ PAGE TABLES 

The page tables referenced by a paged mode iom for ioi_ 
operations are found in i o_page_ tables. It is a abs-wired 
segment J maintained by i o i_page_ table. It starts with a lock and 
indexes of the start of free page table lists. The header ends 
with the size and in_use flags for each page table. The page 
tables themselves are either 64 or 256 words long; each page 
table of length N starts at a 0 mod N boundary and does not cross 
a page boundary within the segment. 



IQl PATA 

ioi_data contains information pertinent to ioi_ (the i/o 
interfacer). It holds ioi's data itself (ioi_data)j, as well as 
group channel and device entries for ioi handled devices. 
ioi_data contains counts of groups^ channels and devices^ 
reconfiguration lock, some flags, and then the channel, group and 
device entries. A channel/devi ce group entry describes a group 
of devices available through a channel. It contains a lock, 
subsystem identifier, various flags describing the device group, 
the number of devices and some counters, A channel table entry 
describes the state of a channel. It holds status flags, the 
io_manager index for the channel, and a place for detailed 
status. A device table entry holds the wired information for an 
ioi device. Besides pointers linking it to the group and channel 
entries, it contains various status bits, workspace pointer, 
ring, process_id and event channels for communication with the 
outer ring caller, timeout and other time limits, offsets into 
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the user's workspace for status storage^ and the idcwj pcWj tdcw 
and status areas. 



IBM DATA 

iom_data describes data in use by i o_ manager , It starts 
with IpWj dcWj sew and status area for stopping arbitrary 
channels. This is followed by various meter Sj such as 
inval id_ interrupts. Following this, for each iom are various 
pieces of state information, on-line, paged mode, etc. It 
concludes with more meters and ending with devtab entry indices. 
For each device, a status are is followed by various flags 
(in_use), channel identification, pew, Ipw and sew, status queue 
ptr, and various times and meters. 



This segment is another hardware known and fixed segment. 
It is used for communication with the various ioms. The segment 
is split into the imw area, which contains a bit per channel per 
iom per interrupt level indicating the presence of an interrupt, 
followed by the mailboxes for sending information to the ioms and 
receiving status back. 



USX fKNQWN SEQhENT IMLLI 

The known segment table is a per-process segment that keeps 
track of hierarchy segments known in a process. Hardcore 
segments do not appear in the kst. The kst effectively provides 
the mapping of segment number to pathname for a process. It is 
the keeper of the description of segments that are initiated but 
not active within a process (as well as those that are active). 
The Initializer's kst is initialized by init_root_dir . It starts 
with a header providing the limits of the kst, as well as 
information such as the number of garbage collections, pointers 
to the free list, what rings are pre- linked, the 256k segment 
enable flag, a uid hash table^ the kst entries and finally a 
table of private logical volumes connected to this process. Each 
kst entry contains a used list thread, the segment number of the 
segment, usage count per ring, uid, access information, various 
flags (directory, transparent usage, etc), an inferior count for 
directories or the Iv index for segments and the pointer to the 
containing directory entry. It is this pointer that allows the 
name of the segment to be found. Also, the segment number of the 
directory entry pointer allows us to find the kst entry for the 
containing directory, etc., allowing us to walk up the hierarchy 
to f i nd the pathname of a segment . 
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V£L tLQGICAL mJJME TABLE) 



The logical volume table consists of an array of entries 
that describe the various logical volumes. It starts with a 
count of entries as well as a maximum count limit. Following 
this is a relative pointer to the first entry and a hash table 
for hashing Ivid (logical volume ids) into Ivt entries. The 
entries that follow^ one per logical volumej contain a relative 
pointer to the threaded list of pvt entries for the logical 
volume^ the Ivid, access clgss info for the volumes and then 
various flags like public and readLonly. It is initialized by 
init_lvt to describe the rlv and maintained by 
I og 1 ca I _ vo I ume_ manager . 



NAME TABLE 

The name_ table contains a list of all of the various names 
by which the segments in the sit (see below) are known. This 
table is used by the sit management routines but especially by 
the various pre-linkerSj who use it to resolve references to 
initialization modules. It is generated from tempi ate_slt_ and 
by the sit management routines^ who read in the names from 
entries on the system tape. 



QC DATA 

oc_data describes data used by ocdcm_ to handle consoles. 
It starts with the required lockj vers i on j device counts^ etc. 
Various flags are kept, such as crash on recovery failure. The 
prompt, discard notice are kept here. Status pointers, times, 
etc. are followed by information on the process handling message 
re-routing. Following this are indices into queues of entries 
followed by the queues. An entry exists for priority i/o (syserr 
output, which alv/ays forces a wait until complete), one for a 
pending read, and 8 for queued writes. After this are meters of 
obscure use. The segment ends with an entry for each configured 
console followed by an entry for each element of a event tracing 
queue. Each console entry provides its name, state, type, 
channel, status, etc. Each i/o queue entry provides room for the 
input or output text, time queued, flags (alert, input/ output, 
etc), and status. 



PHYSICAL RECORD BUFFER 

The physi cal_record_buf f er 
by CO 1 1 ect ion 0 ' s and co 1 1 ect i on 
i/o buffers. 



is a wired area of memory used 
1's MST tape reading routine for 
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Ei£l (PHYSICAL mum. I&BLEi 



One of the disk, describing tables, the physical volume 
table contains an entry for each configured disk drive. It can 
in some ways be considered the master disk describing table in as 
much as performing i/o to a disk drive requires the pvtx ( pvt 
index) of the drive (the index number of the entry in the pvt for 
that drive). The pvt entry contains the physical and logical 
volume id for the drive, various comparatively static flags about 
the drive (such as storage_ system, be ing_ demounted, 
device_ inoperative, etc.), information for the volume dumper and 
information about the size, fullness, vol maps and stocks (both 
record and vtoc) of the drive. This table is allocated by 
get_io_segs, and built by init_pvt. The various brothers in a 
logical volume are chained together in a list by the 
I og i ca I _ volume^ manager so that the vtoc„man can have a set of 
disks from which to select a target for a new segment. During 
initialization, make_sdw$thread_hcp (for init_root_vols) uses 
these threads (before the disk_ table is accessed) to form the 
list of drives which contain hardcore partitions (those eligible 
to contain hardcore segments). 



SCAS (SYSTEM CBNTROLLER ADDRESSING ^E ^MENT? 

This is a very curious pseudo- segment, built by scas_init 
out of page table words generated into scs. It contains one 
pseudo- page for each memory controller (and another page for each 
individual store other than the lowest). The address of the page 
is the base address of the store/control ler . This segment makes 
references to it of the form n« 1 024 to form an absolute address 
to controller n. Thus, instructions like rscr (read system 
controller register) can use this segment (as indeed they do 
inside pr i vi leged_mode_ut) to reference the desired system con- 
troller registers. 



SCAVENGER DATA 



scavenger. data contains information of interest to the 
vo I ume scavenger . I ts header is initial! zed by 

i n i t_scavenger_data. The segment starts with the usual lock and 
wait event. Following this is the pointer to the scavenger 
process table. Then come the meters. The scavenger process 
table, which follows, describes the processes performing 
scavenging operations. Each entry contains a process id of a 
scavenging process, the pvtx of the drive being scavenged, and 
indices of scavenger blocks in use. Scavenger blocks contain 
record and overflow blocks used to keep track of pages of a disk 
(its claiming vtoce and its state). 
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(SYSTEM cgmUN I CAT IQN g 



The scs is a hodge-podge of info^ma^ion about configuration 
and communication between active elements. It contains informa- 
tion about the scus and the cpus. It contains the cow's (connect 
operand words) needed to connect to any given cpu/ioWj the 
interrupt masks used to mask/unmask, the systemj the various smic 
patterns (set memory interrupt eel Is) ^ instructions to clear 
associative memories and the cachej connect and reconfiguration 
lockSj various trouble f lags/ messages used for keeping track of 
pending communication of faults to bce^ cyclic priority switch 
settingsj port numbers for control I erSj configuration data from 
the control lerSj processor data switch values/ maskSj controller 
sizeSj and the seas page table (see seas). 



SLT (SEGMENT LSSmJblS. TA&UE) 

One of the most s i gn i f i cant i n i t i al i zat i on data bases^ the 
sit describes each initialization segment. It is built initially 
from template_sl t_j an aim program that not only builds the 
appropriate sit entries for collection 0 segments^ but also 
generates the dseg for collection 0. Each entry in the sit 
contains: pointers into name_ table of the names and the final 
storage system pathname (and acDj if any^ for the segment; 
access modes^ rings, etc. for the segment; various flags used 
for generat i on/ loadi ng of the segment^ such as 

abs/ init/temp/ super visor segment, wired/paged, etc. j the length 
and bit_countj etc. It is maintained by bootl oad_ s I t_ manager and 
si t_ manager J who build entries based on information on the MST. 
These entries are maintained so that the various pre- 1 inkers 
( bootload_l inker and pre_link_hc) can find the target segments of 
the various references. 



Sai (SY$TEn ?EQMENT IMIbfil 

The sst (which contains the active segment table) is one of 
the most important tables in Multics. It is the keeper of active 
segments. Each active segment has an entry describing it (its 
aste) . The aste contains information used by segment control and 
communicated with page control on the state of a segment. The 
most important part of the entry is the page table words (ptws) 
describing the disk/ memory location of each page. There are four 
pools of astes of different lengths to hold page tables of four 
possible maximum lengths: 4^ 16, 64 and 256 ptws. The entries 
are threaded into various lists. The free entries of the various 
pools are threaded into lists. Active segments have their own 
lists. Separate lists are generated for temp and init (supervi- 
sor) segs. Aside from these threads, each aste also contains 
threads used to link segments to their parents and their trailer 
seg entry. Status information includes: the segment's uid, the 
current length, maximum length and records used, the pvtx and 
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vtocx of the segment (which couple with the ptws to find the 
pages of the segment), various status bits of more obscure usej 
and finally the quota computation information, init_sst origi- 
nally builds this table. The page table words are maintained by 
page control. The entries themselves are maintained by segment 
control . 



SST NAMES 

The sst_names_ segment contains the names of paged segments 
described by the sst. !t is initialized by init_sst_name_seg 
during collection 2 and maintained by segment control only if the 
astk parm appears. It starts with information describing the 
four aste pools followed by the paged segment primary names. 



STACK 0 DATA 

stack,. 0_ data contains information keeping track of the ring 

0 stacks ( stack_0. nnn) that are shared between processes (one per 
eligible process). It is initialized by init_stack_0. It has a 
lock used to control threading of a pool of such stacks. Each 
entry contains a list threadj a relative pointer to the aste for 
the segment J, a relative pointer to the apte for the holding 
procesSj and the sdw for the stack. When this stack is given to 
a processj this sdw is forced into its dseg; the acl of the stack 
is kept as a null acl. 



stock_seg contains the record and vtoce stocks, a part of 
the reliable storage system. Whenever a new page or vtoce is 
needed for a drive, it is obtained from these stocks. The stocks 
are filled by pre- withdrawing a number of records or vtoces from 
the drive. This mechanism is used so that, upon a crash, it is 
guaranteed that any records or vtoces being created were marked 
in the record or vtoc maps as in use. This prevents re- used 
addresses. 



^TR ^m. ^gygTsn i rail se s EPt a ENi) . 

The str_seg is a paged segment used by segment control to 
perform setfault functions- It is initialized into a list of 
free entries by ini t_str_seg. Each entry contains the usual 
backward and forward threads forming a list of trailers for a 
given segment (the list itself is found by a relative pointer in 
the aste for the segment). When needing to fault a segment, this 
list shows all processes containing the segment. The entry shows 
the segment number, for a process with this segment active, of 
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the segment and a relative pointer to the aste for the dseg of 
that process (which is where we need to fault the sdw) . 



SYS INFQ 

sys_info is a keeper of all sorts of information about the 
state of the system. The most important entries to 
initialization are sys_ i nf o$ i ni t i al 1 zat i on_statej which takes on 
values of 1 , 2^ 3 and 4 corresponding to whether we are running 
initialization collection 1 j 2j 3 or whether we are running 
service (beyond collection 3), and sys_ inf oScol lect ion_l_phasej 
which takes on value© defined in col lect ion_1_phases. incl . pll 
corresponding to running early, re.early, boot, bce_crashj ser- 
vice and crash passes through collection 1. Also included are 
key things like". the scu keeping the current time, the current 
time zone, various limits of the storage system, and some ips 
signal names and masks. The variable "max_seg_size" records the 
maximum length of a segment. This value is changed during bee 
operat i on to descr i be the max i mum I ength of a bee paged temp 
segment. This allows various Multics routines to work without 
overflowing segments. Also in sys_info is " bee_max_seg_si ze" , 
this bee maximum segment length. This is available for any user 
ring programs who desire to limit the size of objects they 
prepare for the bee file system. 



See boot load. info J above. 



$YgeRR- PAT A 

The syserr_data segment is part of the syserr logging 
mechanism. syserr actually just writes messages into this 
segment and not to the paged log to avoid problems of paging 
during possible system trouble. It is up to the syserr hproe to 
move these messages from syserr_data to the log, 



SYSERR LSG 

The paged abs-seg syserr^log, which describes the log 
partition of disk, is used to hold the syserr log. It is mapped 
onto the log partition by syserr_log_ init. The syserr mechanism 
involves putting syserr messages into syserr_data (which are 
possibly written to the console) and then waking up the syserr 
hproc which copies them into the paged partition. This is done 
so that page faults are taken by the hproc, not by the syserr 
caller who may be in trouble at the time. It starts with a 
header providing the length of the segment, a lock, relative 
pointers to the first and last messages placed there and also 
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copied out (by the answering service)j the threshold that shov/s 
how full the partition can get before the answering service is 
notified to copy out the messageSj the event channel for 
notification (of the answering service) and the event for 
locicing. Following this are entries for the various syserr 
messages. Each message is threaded with the other sj it has a 
time stampj id number j and the text and optional data portions of 
the message., 



TP PATA 

tc_data contains information for the traffic controller. 
The most obvious entry list herein is the list of aptes (active 
process table entries). There is one apte for every process. 
The apte lists activation information for the process^ such as 
its dbr, its state ( blocked/ runn ing/ stopped/ etc. ) j various 
per-process meters (such as cpu usage) ^ its work classj and other 
per-process scheduling parameters. Following the apt is the itt 
( inter -process transmission table)^ maintained by pxss (the 
traffic controller) to hold wakeups not yet received by a target 
process. The call to hcs_$wakeup (or its pxss equivalent) places 
an entry in the itt containing the target process idj the event 
channelj the message dataj etc. The next call to 
hcs_$read_ events obtains the events waiting for the target 
process. Also present in tc_data is various meters (tern. incl) 
and other flags. Imbeded within this is the wet (work class 
table) which keeps track of the status of scheduling into work 
classes. tc_init builds these tables (see tc_ data_ header ) . 



TC DATA HEADER 

This is a trick initialization segment. tc_data_ header is 
allocated wired storage by tc_init to hold the real tc_data. 
tc_dataj originally build just from a cds segment and therefore 
just describing the header of tc_dataj is copied in. The sdws 
for tc_data and tc_data_ header are then swapped. As suchj the 
initialization segment tc_data_ header (which describes the read 
in tc.data) is deleted^ but tc.data (now mapped onto the 
allocated tc, data. header area) remains, 



The toehold is another area for Mu I t i cs/ boot I oad Multics 
communication. ( Ih particular, the f lagbox is contained within 
it.) The toehold is a small program capable of getting to 
boot load Multics from a crash i ng/ shut i ng down Multics service. 
(Its name is meant to suggest holding on by one's toesj in this 
case to boot load Multics.) in it_ toehold builds a dew (device 
control word) list that, when used by the toehold program, can 
write the first 512k of memory (those used by boot load Multics) 
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out to the bee partition and read in boot load Multics (saved in 
the bee partition by ini t_toehold) . The program runs in absolute 
mode. It is listed here because it contains the flagbox and the 
all important dew lists. 



TTY AREA 

Terminal control blocks (tcb's) are allocated in tty_area. 
It is initialized to an area by fnp_init and managed by the 
various communication software. 



TTY BUF 

The tty_buf segment eontainsj obviously enoughj the tty 
buffers used for manipulating data communicated with the fnp. It 
contains various meters of characters processed, number of calls 
to various operations, echo- negotiation, etc., trace control 
information and timer information. Following this is the 
tty_ trace data, if present, and the tty_buf f er_block' s, split 
into free blocks and blocks with various flags and characters in 
chains. The layout of this segment into empty areas is done by 
f np_ i n i t. 



TTY jmLE,^ 

tty_ tables is an area in which tables (conversion and the 
like) are allocated. It has the usual lock and lock event. It 
is initialized by fnp^init. 



UNPAQSP PA^E TABU^J? 

All permanent non- per -process unpaged segments have their 
page tables in unpaged. page. tables. The page table for this 
segment is also within it. It is generated initially by 
template_sl t_ and added to by the various segment creation 
routines. The header of unpaged. page_ tables contains the abso- 
lute address extents of all hardcore segments that contain page 
tables; these are unpaged. page. tables, int. unpaged. page. tables 
and sst.seg. Dump analyzers look here to resolve absolute 
addresses from sdws into virtual addresses of page tables. 



VTBC BUFFER SE6 

vtoc buffers live in the vtoc.buf f er.seg. The segment is 
allocated and initialized by ini t.vtoc.man. It starts with the 
usual global lock and wait event. Following this are various 
parameters of the amount and usage of the vtoc buffers, including 
information about the vtoc buffer hash table, Then comes the 



B-14 



AN70-01 



vtoc_man meters. Finally comes the hash tablej the vtoc buffer 
descriptors (pvtx - vtocx infOj etc.) and the vtoc buffers 
themselves. 



Wl LINKAGE (WIRED IH ll LINKAGE) 

This initialization segment corresponds to area, linker for 
wired initialization segments. It is built by the MST loading 
rout i nes. 



WIRED HARDC6RE DATA 

Another collection of data for hardcore use^ this segment 
is permanent, It contains the size of a page, the amount to wire 
for temp- wiring appl icat ions, the history register control flagj 
the trap_ i nva I i d_ masked bitj a flag specifying the need for 
contiguous i/o buffers ( if a non-paged iom exists)^ the debg card 
optionsj the f im f au I t_ counters and the bee abort_request flag. 



W$..LI NKAQE tWlEEP. gMPEPVIgQP LINKAGE) 

This wired hardcore segment j shared between pr ocesses^ 
corresponds to area. linker for wired hardcore programs. It is 
built by the MST loading routines. 
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APPENDIX C 



MEMORY LAYOUT 



In the memory layout charts belowj the starting absolute 
address and length for each data area is given (in octal). When 
a number appears in brackets (C])j, this means that it is really a 
part of the segment listed above it. 

The memory layout after the running of collection 0 (the 
loading of collection 1) follows. 



start 


length 


contents 


0 


600 


faulty vector 


1200 


2200 


iom_mai I box 


3400 


3000 


dn355_ ma i 1 box 


10000 


2000 


bos_ toehold 


12000 


10000 


conf i g_ deck 


24000 


22000 


bound_ boot I oad_ 0 


t 24000] 


C4000] 


[(boot load Multics) toehold] 


[24000] 


[2000] 


[flagbox (overlays the toehold)] 


[30000] 


[n] 


[ boo 1 1 oad_ ear I y_ dump] 


46000 


4000 


toehold^data 


52000 


2000 


un paged_ page_tables 


54000 


2000 


i nt_ unpaged. page_ t ab I es 


56000 


2000 


breakpo i nt^page 


60000 


6000 


phy s i ca I _ r ecor d_ buf f er 


66000 


2000 


dseg 


70000 


10000 


name_ table 


1 00000 


4000 


sit 


1 04000 


2000 


lot 


1 06000 


and up 


wired segments 






f abr 1 cat ed segmen t s 


1777777 


and down 


al I other segments 



The absolute addresses of most of these segments is 
arbitrary. Hardware known data bases must be at their proper 
places^ though; also^ the toeholds are placed at addresses known 
to operators. Except for these exceptions, the segments may be 
moved. Their addresses are contained in boot load_equs. incl.alm. 
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All programs refering to this include file must be reassembled if 
these addresses are changed. Certain interdependenci es exist 
that one must be aware of. First of allj the toehold is placed 
at a 0 mod 4 page address. physi cal^ record^ buffer must be the 
last of the fixed memory address segments. The length of all 
segments is an integral number of pages. The two unpaged page 
tables segments must be large enough to i^ieet the demands on themj 
refer to announce_chwm. AlsOj the length given for 
bound_boot load_0 must hold the text thereof. 

After collection 1 has finishedj segments have been made 
paged and collection 1 temp segments have been deletedj the 
memory layout is as follows. 



start 


length 


contents 


0 


600 


f au I t_ vector 


1200 


2200 


i om_mai I box 


3400 


3000 


dn355_mai I box 


10000 


2000 


bos_ toehold 


12000 


10000 


config_deck. 


24000 


4000 


toehold (boot load Multics) 


C 24000] 


E20003 


Cflagbox (overlays the toehold)] 


46000 


4000 


toehold_data 


52000 


2000 


unpaged. page_ t ab I es 


56000 


2000 


breakpo i nt_page 


60000 


and up 


paging area 


high mem 




sst_ seg 
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INDEX 



A aste pools 3-12j B-10 



aborting bee requests 

see bcej aborting requests 

abs-seg 3-10j 3-13, 3-16, 

3- 17, 3-18, 3-19, 4-3, 

4- 5, 4-16, 4-18, 6-8, A- 1 , 
B-2 

absolute mode 2-2 

accept_f s_di sk 6-3 

accept_rpv 6-3, 8-14 

act i ve i n i t I i nkage 
see a i _ I i nkage 

act i ve segment tabl e 
see sst 

active supervisor linkage 
see as_ I i nkage 

ai.linkage 2-7, 3-20, B-1 

announce_chwm 3-8 

appending simulation 4-4 
see also bce_dump and 
bce_probe 

ar ea . I i nker 

see I i nkage sect i ons 

assume_ conf i g_ deck 2-7 



as_ linkage 2-7, 3-20, B-1 



B 



bee 1-3, A-1 

aborting requests 3-18, 4-6, 
4-11 

alert messages 4-4 

area usage 4-2 

command level 4-10, 4-15 

bce_ crash 3-2 

boot 3- 1 

crash 3- 1 

early 3-1 
command processing 4-2, 4-9, 
4-11 

communication with Multics 
B-5 

conf ig_ deck manipulation 

4-17 
data B- 1 

disk accessing 4-3, 4-16 

error reporting 4-2, 4-8 

exec_com 4-9 

facilities 4-1 

file system 3-16, 4-3, 4-16, 

4-18 
f i rmware 

loading 4-10 
i/o switches 4-2, 4-7, 4-18, 

B-1 

initialization 4-1, 4-18 
invocation upon a crash 
B-1 4 
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bee (cont) 

machine state 5-2 
paged programs 3-16 
partitions 

creation 3-6^ 3-9, 3-13 
usage 3-16, 4-\, 4-3, 
4-16, 4-17, 4-18 
probe 4-7, 4-8, 4-10, 4-11, 
4-14, 4-15 
current address 4-13, 
4-14 

question asking 4-2, 4-14 

ready messages 4-15 

rei n i t i al i ze 4-10 

request processing 4-2, 4-6 

request table 4-15 

restrictions 4-3 

temp segments 4-3, 4-17 

bce_ abs_ seg 4-4 

bce_ alert 4-4 

bce_alm_die 4-4 

bce_appendlng_simulat ion 4-4, 
4-8, 4-14 

bce_check._ abort 4-6 

bce_ command^ processor _ 4-6 

bce_console„ io 4-7 

be©- con t i nu e 4-7 

beeper ash bee command level 
see bee, command level, 
beeper ash 

bce.data 4-7, B-1 

bce^die 4-7 

bce_ disp I ay_ instruct ion_ 4-7 
bce_ d i sp I ay_ scu_ 4-8 
bce_dump 4-8 
bce_ err or 4-8 
bce_esd 4-9 



bce_ ex ecu te_ command^ 4-9 

bce_exec_com_ 4-9 

bce^ ex ec_ com_ i npu t 4-9 

bce_fwload 3-16, 4-10 

bce_get_f lagbox 4-10 

bce_get_to_commancL level 4-10 

bce_ inst_ length_ 4-10 

bce_ I i sten_ 4-11 

bee. I i st_requests_ 4-11 

bce.map_over_requests_ 4-11 

bce_name_to_segnum_ 4-11 

bce_ probe 4-11 

see also bee, probe 

bce_probe_data 4-14 

bce_ query 4-14 

bce_ r eady 4-15 

bce_relocate_ instruct ion_ 
4-15 

bce„request_table_ 4- 15 

bce_ severity 4-15 

bce_ shutdown. state 4-15 

bce_ state 4'- 16 

boot 

cold 3-13, 6-4, 6-7, A-1 

cool A- 2 

from bee 4-10 

from BOS 2-1 

from disk A-6 

from lorn 2-1 

from tape A- 2 

initial A-1 

warm A-6 
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boot bee command level 

see bee J command levels boot 

boot load command environment 
see bee 

boot load command environment 
data 
see bce_data 

boot load Multics 1-1, A-1 

bootload_0 2-3 

bootload^l 3-8 

bootload_abs_mode 2-2 

boot I oad_ console 2-^4 

boot load_disk._post 4-16 

bootload_dseg 2-4j 8-1 

bootload^ear ly_dump 2-5 

boot I oad_ error 2-5 

bootload_f aults 2-5 

bootload^f i le_parti t ion 4-16, 
4-18 

bootload_f lagbox 2-6 
bootload_f orml ine 2-6 
bootload_fs_ 4-16 
boot load_f s_cmds_ 4-17 
bootload_ inf o B-1 
bootload_io 2-6 
bootload_ I inker 2-7 
boot load. loader 2-7, 8-1 
boot load. qedx 4-17 
boot I oad_s I t_ manager 2-7 



bootload_tape_f w 2-8 

boot I oad.tape_ label 2-1, 8-1 

boot_rpv_ subsystem 3-8 

boot_tape_io 3-8 

BOS 

getting to from bee 4-7 
presence of 2-7 

bound. boot I oad_0 2-1, 8-1 

breakpoints 3-15, 3-16, 3-17, 
4-12, 4-13, 4-14, 5-2 
see also breakpoint. page 

breakpoint. page 2-7, 3-9, 
3-16, 3-17, 3-18, A-5 
see also breakpoints 



C 



central processor 
see cpu 

channel table entry 7-2, B-6 

ehantab B- 3 

clock 
. sett i no 3-12 

cold boot 

see boot, cold 

CO 1 1 ect i on 1 - 1 , A- 2 

collection 0 1-2, 2-1 
console support 2-4 
data B- 1 

error handling 2-5 
input/ output 2-6 
interrupts 2-6 
main driver 2-3 
programming in 2-2 

collection 1 1-2, 3-1 

bee. crash pass 3-2, 3-7 
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collection 1 (conii) 
boot pass 

sequence 3-2 
boot load Multics pass 3-1 
crash pass 3-1j 3-7 
early pass 3-1 

sequence 3-5 
passes summary 3- 1 
re_ early pass 3-2, 3-7 
see also bee 
service pass 3-1 

sequence 3-4 
shut pass 3-1 J 3-7 

col Vect ion 2 1-3 

loading 3-20 
pre- I i nki ng 3-18 
sequence 6- 1 

collection 3 1-3, 7-1 

col lection_1_phase B''12 

col lect_f ree_core 3-9 

conditions 

signal I ing 3-15 

configuration 
data 

see config_deck and scs 
initialization sequence 

8- 1 1 
memory 8-5 

config_deck 3-10, B-2 
changes to 4-10 
editing 4-17 
initial generation 3-12 
setup 3-5 

conf i g_deck_data_ 4^17 

conf ig_deck_edit_ 3-10, 4-17 

connect operand words 3-20 

console 

collection 0 2^4 
dr i ver 

see ocdcm_ 
locating 2-4 



contiguous A- 2 

cool boot 

see boot J cool 

core high water mark. 3-8 

core_map 3-14, 3-17, 8-13, 
B-2 

cow 

see connect operand words 

cpu 

data B-10 
description 8-4 
initialization of data 3- 
starting 6-9, 7-3 

crash A- 2 

early in initialization 5 
handler 3-1, 3-3 
handl ing 1-4, 5-1 
i mage 

access 4-4 

restarting 4-7, 5-2 
machine state 5-1 
memory saving 5-1 
memory state B-13 
memory swapp i ng B-13 

crash bee command level 
see bee, command level, 
crash 

create_root_dir 6-4 
create_root_ vtoce 6-4 
create. rpv_ part i t i on 3-9 
cte 

see channel table entry 



D 



data 

about act i ve segments B-10 
about bee B- 1 
about boot load tape B-1 
about collection 0 B-1 
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data (cont) 

about configuration 

see conf ig_cleck. and scs 
see i o_conf i g„data 
about core frames B-2 
about CPUS B- 1 0 
about hardcore segments 
B-10 

about processes B-13 
about rpv B-2 
about storage system B-12 
about system controllers 
B-10 

about system state B- 1 2 
data bases B-1 
dbm_man 6-4 
dbm_seg 6-4, B-3 
dbr B-4 

deact i vat e_for_ demount 9-4 

deciduous segments 

see segments^ deciduous 

de\ete_segs 3-9 

demount_pv 9-5 

deposit A- 3 

descr i ptor segment 

see dseg 

descr i ptor segment base 
regi ster 
see dbr 

device table entry 7-2j B-6 

devtab B-3 

directory 

locking B-3 

dir_ \ock_ init 6-4, 8-14 

dir_lock_seg 6-4, B-3 



disk 

accessing 3-19, A- 1 , B-9 
i/o posting B-3 
storage system 

acceptance 6-3 

demounting 9-5 

disk queue B-3 
disktab B-3 
disk_data B-3 
disk_ emergency 9-5 
disk_post_queue_seg B-3 
disk_ reader 3-9 
disk_seg 3-1 1, B-3 
dm^ journal _seg_ 6-6, B-4 
dn355^data B-4 
dn355_mai Ibox 6-5, B-4 
dseg 2-8, 3-17, A- 3, B-4 
dte 

see device table entry 

dump 

early 2-5, A- 3 
to disk 4-8, A- 3 
to tape A- 3 

dumper bit map seg 
see dbm_seg 



E 



early bee command level 
see bee, command level, 
early 

early initialization 
dumps 2-5 

see initialization, early 
emergency shutdown 4-9 
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emergency shutdown (cont) 
see shutdown J emergency 

emergency. shutdown 9-5 

errors 
hand I i ng 

in bee 3-14 

in collection 0 2-5 
reporting 

bee 4-8 

syserr B- 1 2 
see also failures 

esd 

see shutdowns emergency 

establ ish_conf ig_deck 3-10 

establ ish_temp_segs 4-8j A-M 

execute interrupt cell 
register 8-8 

execute interrupt masi^;. 
register 8-9 



F 



f ai lures 

of boot initialization 3-2 
of Multics A- 2 
of service initialization 
3-'2 

see also errors 

fast connect code 3-18 

fau I t_ vector 2-5 
see also vectors 

f i I l_vol_extents_ 3-10 

fim 5-2 

f ind_f i le_part ition 4-18 
f ind_rpv_ subsystem 3-10 



firmware 
loading 

general mpcs 3-11 
in bee 4-10 

into boot tape controller 

2- 8 

non- boot load disk mpcs 

3- 3, 3-16 

rpv disk mpc 3-6^ 3-8 
location 4-10 

for boot tape mpc 2-3 
naming 2-3 

flagbox B-5 

management 2-6j A-7 , 4-10 

fnp_init 6-4 

fsout_vol 9-6 



6 



gates 

initialization 6-6 
1 i nkages 8- 1 5 

getuid 6-5, 8-14 

get_io_segs 3-11 

get^main 3-11, 8-2 

group table entry 7-2, B-^6 

gte 

see group table entry 



H 



hardcore A- 3, A- 5 
address space 6-1 

hardcore partition 
accessing 3-13 
allocation from 3-17, 6-3 

amount of utilization 6-3 
locating 3-13 
usage 6-S, 8-2, A- 2, A- 4 
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hardcore segments 
creation 8-1 
numbering 6-Sj 8-15 

hardware 

configuration 8-5 
Inter- connect ion 8-3 
inter -module communication 
8-7 

hc_ I oad_ mpc 3-11 
hproc 6-10, A- 3 



I 



idle loop 6-7 

idle process 6-9^ 6-lOj 8-16 

init segments 3~9 
see segmentSj init 

initialization A- 3 
bee 4-1/ 4-18 
boot fai lure 3-2 
configuration 8-3 

sequnce 8-11 
directory control 6- 1 j 8-14 
disk, control 3-3 
ear I y A- 3 
file system 1-3 
gates 6-6 
hardware 8-3 
I inking of A- 4 
page control ^-2, 3-3, 8-13 
pl/1 environment 1-2 
rpv 3-14 
scu 3- 1 4 

segment control 6-1, 8-14 
service failure 3-2 
storage system 6- 1 
summary 1-1 

traffic control 3-21, 6-1, 
8-16 

initial ization_ state B-12 
initializer 3-15 



initializer stack. 

see stack, initial! zat i on 

initial ize_faults 3-15, 6-9 

initial ize_faults_ data 3-15 

init ial_error_handler 3-14 

init_aste_ pools 3-12 

init^bce 4-18 

init_ branches 6-5, A- 2 

init_clock.s 3-12 

init_dm_journal_seg 6^6 

init_early_conf ig 3-12 

ini t_empty_root 3-12 

i ni t_ hardcore. gates 6-6 

init_hc_part 3-13 

init.lvt 6-6, 8-14 

init_partit ions 3-13, 8-14 

init_proc 7-1 

ini t_ processor 6-6, 8-16 

init.pvt 3-13, 8-13 

ini t_root_dir 6-7, 8-14 

ini t_root_ vols 3-13, 8-13 

init_scavenger_data 6-7 

init_scu 3-14 

init_sst 3-14, 8-13 

init_sst_name_seg 6-7 

init_stack_0 6-7 

init_str_seg 6-8, 8-14 



i-7 



AN70- 



init_sys_var 6-8 

i n i t„ toeho I d 5-1, 5-2, B-13 

init_volmap_seg 6-8 

init^vo I _ header 3-14 

ini t_vioc_man 6-9, 8-14 

input/ ou^put 

in collection 0 2-6 

inter -process transmission 
table 
see i tt 

interrupt mask, assignment 
register 8-9 

interrupt vectors 

see vectors, interrupt 

interrupts 

collection 0 2-6 
mask assignment 8-9 
mask operations 8-10 
mask values 8-11 

i nt_unpaged_page_ tabl es 
see segments, unpaged 

inzr_stkO 

see stack, initialization 

ioi_ 7-2 

ioi_data 3-11, B-6 
ioi_init 7-2 
ioi_pag&_ table 7-3 
iom 

description 8-4 
iom_data 3-11, 3-16, B-7 
iom_data_ ini t 3-16, 8-11 
iom_,mailbox B-7 
io_conf ig_data 3-11, 7-2, B-6 



io_conf ig_ init 7-2 

i o_ page_ tab I es 

see page tables, paged mode 
iom 

itt B-13 



K 



known segment table 
see kst 

kst 6-9, 8-14, A-4, B-7 

kst_util 6-9 



L 



let B-4 

linkage sections 2-7, 3-20, 
B- 1 , B- 1 5 
hardcore gates finding 6-6 

I i nking 

see pre- I inking 

loading 

of collection 0 2-1 

of CO II ect ion 1 2-7 

of collection 2 3-20 

of collection 3 7-3 

load_.disk_mpcs 3-16 

load_mst 3-16 

I oad_ system 7-3 

I ock i ng 

directories 6-4 

logical channel table 
see I ct 

logical volume table 

see I vt 
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Ivt 6-6, 8-14, A-4, B-8 



0 



M 



mai I boxes 

datanets B-4 
iom 3-16, B-7 

make_sdw 3-16, 3-21, 8-2 

mak.e_ segs_ paged 3-17, A- 5 , 
B-6 

memory 

accessing A- 1 
allocation 3-11 
allocation from sit 3-3, 

3-11, 8-2 
extent of usage 3-9 
freeing 3-9, 3-17 
layout A- 2 

after collection 0 C-1 

after mak.e_segs_ paged C-2 

announcing 3-6 

placement 3-17 

required placement C-1 
paging use 3-9 
requirements for boot load 
3-4 

move_non„perm_wired»segs 3-17 

MST 3-16, 3-20, A- 4 

disk reading 3-9 

tape reading 3-8, 3-21 

mult i -programming 6-10 

Multics system tape 
see MST 



name_ table 2-8, B-8 

nondeciduous segments 

see segments, nondeciduous 



ocdcm_ 3-18, 4-6, 4-7 
data B- 8 

oc_data B-8 

see also ocdcm_, data 



P 



page table word 
see pt.w 

page table word associative 
memory 
see ptwam 

page tables 

absolute to virtual 

addresses B- 1 4 
act i ve segments B- 1 0 
paged mode iom 7-2, B-6 
seas B- 1 0 

see also unpaged page tables 
unpaged segments 

see segments, unpaged 

paging 

of bee segments 3- 16, 4-1 
of initialization segments 
3-17 

partition A- 4 

see bee, partitions 
see hardcore partition 

pathname associative memory 
6-7 

phys i ca I vo I ume 
see disk 

physical volume table 
see pvt 

physical_record_buf f er B-8 

pll environment 
setup 3-8 
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prds^init 3-18 

pre- Unking 2-1, A- 4 
initialization A- 4 
of collection 0 2-1 
of collection 1 2-7 
of collection 2 3-16 

pre- withdrawing B- 1 1 

pre_ I ink_ he 3-18 

probe 

see bee, probe 4-7 

ptw A- 4 

ptwam A-4, A-5 

pvt 3-11 J 3-13, 8-13, A-4, 
B-9 



R 



read_diskL 3-19, 8-13 

read_disk_ label 3-19, 8-13 

r ead_ ear I y_dump_t ape 2-5 

real_ initial izer 3-19 

reinitialize 4-10 

reload 7-1 

request table 

see bee, request table 

ring 1 command level 7-1 

root dir 

activation 6-7 
creation 6-4, 6-7 

root physical volume 
see rpv 

rpv A-5 

initialization 3-12 
layout 3-10 



rpv (cont) 

locating 3-10 



S 



saf e_ conf i g_ deck 3-3 
salvaging 6-3, 6-5, 6-8 
save_handler_mc 5-2 
seas 3-20, A-5, B-9 
scas_init 3-20 
scavenger 9-6 
scavenger. data 6-7, B-9 
scs 3-20, A-5, B-10 
scs_and_clock_ ini t 3-20, 8-11 
SCU 

addr ess i ng 8-6 
data B-10 
description 8-3 
initialization of data 3-20 
register access B-9 

sdw 2-4, 8-2, A-5, B-4 
creation 3-16 

segment descriptor word 
see sdw 

segment descr i ptor word 
associative memory 
see sdwam 

segment loading table 
see sit 

segments 

activation information B-7 
deact i vat i on 9-4 
deciduous 6-5, 8-3, 8-15, 

9-4, A-2 
har dcore 
data B-10 
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segments (cont) 
hardcore 

permanent 

numbering 8-15 
hierarchy 

numbering 8-15 
init 3-9j A-3 

numbering 8-15 
nondeciduous A- 4 
number i ng 

fixed 8-15 

outer r i ng B- 7 
synchronized 6-8, B-4 
temp 3-9j A-5 

number i ng 8-15 
unpaged A-S, B-6, B-14 

segment^ I oader 3-20 

setfault B-11 

shutdown 9-1j 9-6, A-5 
emergency 4-9, 9-3, 9-5, 
A-3 
part 1 9-2 
normal 9-7 

shutdown^ f i 1 e„ system 9-7 

shutdown_ state 9-6 

sit 2-7, 2-8, 3-21, A-5, B-8, 
B-10 

memory allocation from 
see memory, allocation 
from sit 

s I t_ manager 3-21 

sst 3-14, 3-17, 8-13, 8-14, 
B-11 

sst_names_ 6-7, B-11 

stacK 

collection 0 2-2 
initialization B-5 
r ing 0 6-7, B- 1 1 
segment number i ng 8-15 
shutdown 9-4, 9-6, 9-7, B-5 

stack_0_data B-11 



start- cpu 6-9, 8-16 

stocks 3-11, 8-13, 9-6, B-9, 
B-11 

stocky seg B- 1 1 

stop on switches 3-20 

str_seg 6-8, B-11 

supervisor 
see hardcore 

sw i tches 
i/o 

see bee, i/o switches 

swi tch_shutdown_f i I e_ system 
9-7 

synchronized segments 

see segments, synchronized 

syserr_data B- 1 2 

syserr_log 6-9, B-12 

syserr_log_ init 6-9 

system communications segment 
see scs 

system controller 
.see sou 

system controller addressing 
segment 
see seas 

system segment table 
see sst 

system trailer segment 
see str_seg 

system_type 2-7 

sys_boot_ i nf o B- 1 

sys_info B-12 
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sys inf o$bce_max_seg_si2e 
4-18 



T 



tape_ reader 3-21 
tcb B- 1 4 

^c_da^a 3-21, B-13 

tc_ da ta_ header B- 1 3 

tc.init 3-21, 6-10, 7-3, S- 1 6 

tc_ shutdown 9-7 

temp segments 3-9 
see segments, temp 

template_slt_ 2-8, 8-1, B-S, 
B-6, B-8, B-10, B-14 

terminal control blocks 
see tcb 

toehold 2-5, 5-1, 8-1, B-13 
entry points 5-1 

traffic control 
data B- 1 3 
initial izat ion 

see initialization, 
traiff ic control 
shutdown 9-7 

tty_area 6-4, B-14 

tty_buf 6-4, B^14 

tty_ tables 6-5, B-14 



U 



uid 6-5, 8-14, A-5 



unpaged page tables 2-' 7, 2-8, 
3-8, 3-11, 8-2 

unpaged segments 

see segments, unpaged 



V 



vectors 

fault B-5 
initialization 3-15 

col lection 2 6-9 
interrupt B-5 
see also fau I t_ vector 
setup 2-5 

volmap^seg 6-8 

volume table of contents 
see vtoc 

vtoc A- 6 

accessing 6-8 
updating 9-5, 9-6 

vtoce A- 6 

accessing 6-3, 6-9, 8-14 
buffers 6-9, 9-7, B-14 
creat i on 

deciduous segments 6-5, 
8-3 

initial 3-14 

root dir 6-4 
deactivation 9-5 
dumper bit B-3 
scavenger B-9 
specifying number 3-13 
stock 9-6, B-9, B-11 
updating 6-8, 9-1, 9-4 
updating for partition 
creation 3-9 

vtoc_buf f er_seg B-14 



W 



un i que i dent i f i er wakeups B-13 

see uid 
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warm boot 

see boot J warrn 

wired A-6 

wired init linkage 
see wi_ 1 i nkage 

wired supervisor linkage 
see ws_ I i nkage 

wi red_hardcore_data B-'IS 

wi red_shutdown 9-7 

withdraw A-6 

wi_ linkage 2-7, 3-20, B-15 
ws_ linkage 2-7, 3-20, B-15 
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